M2000 HA System Administrator Guide (Sun, S10)

M2000 V200R010
HA System Administrator Guide (Sun, S10)

Issue Date 03 2010-08-31
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2010. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd. All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or implied. The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute the warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China http://www.huawei.com support@huawei.com
Website: Email:
Issue 03 (2010-08-31)
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.
About This Document
About This Document
Purpose
This document is applicable to the M2000 HA system based on the Solaris 10 and Sybase 15. It describes the concepts related to system management tasks, procedures for performing such tasks, routine and emergency maintenance of the system, usage of common commands and tools, and troubleshooting.
Related Versions
The following table lists the product version related to this document. Product Name M2000 Version V200R010
Intended Audience
The intended audiences of this document are network administrators.
Revision History
03 (2010-08-31)
The third formal release. Compared with 02 (2010-08-05), the following content is modified. Content 2.4.1 Powering On the M2000 (HA, T5220)
Issue 03 (2010-08-31)
Description The content descriptions are changed.
iii
About This Document
Content 9.1 Introduction to M2000 Processes and Services 16.1.18 How Should I Configure the Monitoring Function for the S3000 Series Disk Arrays 16.1.19 How Should I Uninstall the OceanStor Monitoring Software
Description The content descriptions are changed. New added.
New added.
02 (2010-08-05)
The second formal release.
01 (2010-07-10)
Initial release. Also, the first formal release.
Organization
1 M2000 High Availability System This chapter describes the features, working principles, logical architecture, and software architecture of the M2000 HA system. 2 Powering the M2000 On or Off (HA) This chapter describes how to power on and power off the M2000 HA system. 3 Managing Cluster Resources of the M2000 (HA) This chapter describes how to manage the cluster resources of the M2000 HA system. 4 Setting the M2000 Time (HA) This chapter describes how to set the server time and the client time to ensure that the specified time meets the requirements and is synchronized with the Huawei mobile equipment. 5 Configuring the IP Address of the M2000 Server (HA) This chapter describes how to set the host name and IP address of the server in the M2000 HA system. 6 Managing the M2000 Clients This chapter describes how to manage the M2000 clients. The graphic user interface (GUI) on the M2000 client supports the O&M for the NEs and enables you to monitor the M2000. You must manage the M2000 clients to ensure their normal operation. 7 Managing the M2000 Users (HA)
iv Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 03 (2010-08-31)
About This Document
This chapter describes the four types of users involved in the operation of the M2000 system: Solaris user, Sybase user, network management user, and NE user. In addition, it describes the management and monitoring operations related to the types of users and M2000 user groups. 8 Managing OSS System (HA) The M2000 provides the OSS management function. By using this function, you can viewing NE partitioning, managing the M2000 license, monitoring the M2000 server, integrated task management, check OMC status, collecting NM log files. 9 Managing the M2000 Processes and Services (HA) This chapter describes how to manage the processes and services of the M2000 HA system. The management of the processes and services ensures the smooth operation of the M2000 HA system. 10 Managing the M2000 Databases This chapter describes how to manage the M2000 databases. 11 Managing the M2000 Files and Disks (HA) This chapter describes how to manage the file systems and disks on the M2000 server and client. 12 Backing Up and Restoring the M2000 (HA) This chapter describes how to back up and restore the M2000 HA system. 13 M2000 Routine Maintenance (HA) This chapter lists the maintenance items and provides guidance for the routine maintenance of the M2000 HA system. You can add or delete the maintenance items based on requirements. 14 M2000 Emergency Maintenance (HA) This chapter describes the emergency maintenance procedures for serious faults in the server and clients of the M2000 HA system. These procedures include the emergency maintenance for the server in the M2000 HA system and the M2000 clients, and the procedure for powering off the M2000 server in exceptional situations. 15 Troubleshooting the M2000 This chapter describes the procedures for troubleshooting the M2000. 16 FAQs (HA, Sun) This chapter describes some frequently asked questions (FAQs) and the answers regarding the M2000 HA system.
Conventions
Symbol Conventions The symbols that may be found in this document are defined as follows. Symbol Description Indicates a hazard with a high level of risk, which if not avoided,will result in death or serious injury.
Issue 03 (2010-08-31)
About This Document
Symbol
Description Indicates a hazard with a medium or low level of risk, which if not avoided, could result in minor or moderate injury. Indicates a potentially hazardous situation, which if not avoided,could result in equipment damage, data loss, performance degradation, or unexpected results. Indicates a tip that may help you solve a problem or save time. Provides additional information to emphasize or supplement important points of the main text.
General Conventions The general conventions that may be found in this document are defined as follows. Convention Times New Roman Boldface Italic Courier New Description Normal paragraphs are in Times New Roman. Names of files, directories, folders, and users are in boldface. For example, log in as user root. Book titles are in italics. Examples of information displayed on the screen are in Courier New.
Command Conventions The command conventions that may be found in this document are defined as follows. Convention Boldface Italic [] { x | y | ... } [ x | y | ... ] { x | y | ... }* Description The keywords of a command line are in boldface. Command arguments are in italics. Items (keywords or arguments) in brackets [ ] are optional. Optional items are grouped in braces and separated by vertical bars. One item is selected. Optional items are grouped in brackets and separated by vertical bars. One item is selected or no item is selected. Optional items are grouped in braces and separated by vertical bars. A minimum of one item or a maximum of all items can be selected.
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 03 (2010-08-31)
vi
About This Document
Convention [ x | y | ... ]*
Description Optional items are grouped in brackets and separated by vertical bars. Several items or no item can be selected.
GUI Conventions The GUI conventions that may be found in this document are defined as follows. Convention Boldface > Description Buttons, menus, parameters, tabs, window, and dialog titles are in boldface. For example, click OK. Multi-level menus are in boldface and separated by the ">" signs. For example, choose File > Create > Folder.
Keyboard Operations The keyboard operations that may be found in this document are defined as follows. Format Key Key 1+Key 2 Key 1, Key 2 Description Press the key. For example, press Enter and press Tab. Press the keys concurrently. For example, pressing Ctrl+Alt +A means the three keys should be pressed concurrently. Press the keys in turn. For example, pressing Alt, A means the two keys should be pressed in turn.
Mouse Operations The mouse operations that may be found in this document are defined as follows. Action Click Double-click Drag Description Select and release the primary mouse button without moving the pointer. Press the primary mouse button twice continuously and quickly without moving the pointer. Press and hold the primary mouse button and move the pointer to a certain position.
Issue 03 (2010-08-31)
vii
Contents
Contents
About This Document...................................................................................................................iii 1 M2000 High Availability System............................................................................................1-1
1.1 Features and Working Principles of the HA System.......................................................................................1-2 1.2 Logical Architecture of the HA System..........................................................................................................1-3 1.3 Software Architecture of the HA System........................................................................................................1-3
2 Powering the M2000 On or Off (HA).....................................................................................2-1

2.1 Powering the M2000 On or Off (HA, Netra 240)...........................................................................................2-2 2.1.1 Powering On the M2000 (HA, Netra 240).............................................................................................2-2 2.1.2 Powering Off the M2000 (HA, Netra 240)............................................................................................2-4 2.2 Powering the M2000 On or Off (HA, V890)..................................................................................................2-6 2.2.1 Powering On the M2000 (HA, V890)....................................................................................................2-6 2.2.2 Powering Off the M2000 (HA, V890)...................................................................................................2-9 2.3 Powering the M2000 On or Off (HA, E4900)..............................................................................................2-12 2.3.1 Powering On the M2000 (HA, E4900)................................................................................................2-12 2.3.2 Powering Off the M2000 (HA, E4900)................................................................................................2-16 2.4 Powering the M2000 On or Off (HA, T5220)..............................................................................................2-18 2.4.1 Powering On the M2000 (HA, T5220)................................................................................................2-19 2.4.2 Powering Off the M2000 (HA, T5220)................................................................................................2-21 2.5 Powering the M2000 On or Off (HA, M4000/M5000) ................................................................................2-23 2.5.1 Powering On the M2000 (HA, M4000/M5000)...................................................................................2-24 2.5.2 Powering Off the M2000 (HA, M4000/M5000)..................................................................................2-27
3 Managing Cluster Resources of the M2000 (HA).................................................................3-1

3.1 Introduction to Cluster Resources of the M2000 (HA)...................................................................................3-2 3.1.1 Work Principle of the Sun Cluster......................................................................................................... 3-2 3.1.2 Resource Planning for the M2000 (HA)................................................................................................3-3 3.1.3 Automatic Switchover Conditions of Active and Standby Nodes.........................................................3-3 3.2 Switching Over Active and Standby Nodes....................................................................................................3-4 3.2.1 Automatic Switchover Conditions of Active and Standby Nodes.........................................................3-4 3.2.2 Manually Switching Over Active and Standby Nodes (HA).................................................................3-5 3.3 Registering the resource of the Sybase........................................................................................................... 3-7 3.3.1 Installing the Sybase Agent (HA).......................................................................................................... 3-8 3.3.2 Modifying the File sybase_stop_servers in the Folder /opt/SUNWscsyb/bin....................................... 3-9 Issue 03 (2010-08-31) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. ix
Contents
HA System Administrator Guide (Sun, S10) 3.3.3 Modifying the File sybase_start in the Folder /opt/SUNWscsyb/bin..................................................3-10 3.3.4 Registering the Sybase to the Sun Cluster...........................................................................................3-10 3.3.5 Checking the Register of the Sybase Resource....................................................................................3-11 3.3.6 Activating sybase_rs............................................................................................................................3-12
3.4 Registering the resource of the M2000.........................................................................................................3-13 3.4.1 Installing the M2000 Registration Package.........................................................................................3-13 3.4.2 Registering the M2000 Server Application to the Sun Cluster(Netra240&V890&E4900).................3-14 3.4.3 Registering the M2000 Server Application to the Sun Cluster (T5220&M4000&M5000)................3-15 3.4.4 Checking the Register of the M2000 Server Application....................................................................3-15 3.4.5 Activating M2000 Resources...............................................................................................................3-16 3.5 Managing Cluster Resources.........................................................................................................................3-18 3.5.1 Viewing Configured Resources...........................................................................................................3-19 3.5.2 Starting Cluster Monitoring on Resources...........................................................................................3-19 3.5.3 Stopping Cluster Monitoring on Resources.........................................................................................3-19 3.5.4 Starting the M2000 Services (HA).......................................................................................................3-20 3.5.5 Stopping M2000 Services (HA)...........................................................................................................3-21 3.5.6 Starting the Sybase (HA)......................................................................................................................3-21 3.5.7 Stopping the Sybase (HA)....................................................................................................................3-22
4 Setting the M2000 Time (HA)..................................................................................................4-1

4.1 Time Management for the Huawei Mobile Network......................................................................................4-2 4.1.1 Introduction to Time Synchronization...................................................................................................4-2 4.1.2 Introduction to the NTP/SNTP...............................................................................................................4-3 4.1.3 Time Synchronization Modes of Huawei Mobile Network...................................................................4-6 4.1.4 Introduction to the DST........................................................................................................................4-12 4.2 Modifying the Date and Time on the M2000 Server (HA)...........................................................................4-12 4.3 Changing the Time Zone of the M2000 Server Without Using DST (HA)..................................................4-14 4.4 Modifying the Date, Time, and Time Zone on the M2000 Client................................................................4-16 4.5 Configuring the NTP Service of the M2000 (HA)........................................................................................4-17 4.5.1 Checking the Time Settings of the M2000 Server (HA)......................................................................4-18 4.5.2 Setting the M2000 Administration Console as the Secondary NTP Server.........................................4-18 4.5.3 Starting the NTP Service on the M2000 Administration Console.......................................................4-20 4.5.4 Checking the Running Status of the NTP Service on the M2000 Administration Console.................4-20 4.5.5 Setting the M2000 Server as an NTP Client (HA system)...................................................................4-21 4.5.6 Starting the NTP Service on the M2000 Server (HA).........................................................................4-23 4.5.7 Checking the Running Status of the NTP Service on the M2000 Server (HA)...................................4-24 4.5.8 Setting the NTP Service on the M2000 Client.....................................................................................4-25 4.6 Setting DST for the M2000 (HA).................................................................................................................4-27
5 Configuring the IP Address of the M2000 Server (HA)......................................................5-1

5.1 Adding or Deleting a Route of the M2000 Server..........................................................................................5-2 5.2 Changing the IP Address of the M2000 Server (HA).....................................................................................5-3 5.3 Changing the IP Address of Ethernet Port nxge3 on the M2000 Server (HA).............................................5-12 5.4 Modifying the IP Address of the SC or RSC or XSCF on the M2000 Server..............................................5-14 x Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 03 (2010-08-31)
Contents
5.4.1 Modifying the IP Address of the SC on the Netra 240 Server.............................................................5-14 5.4.2 Changing the IP Address of the RSC on the V890 Server...................................................................5-15 5.4.3 Modifying the IP Address of the SC on the E4900 Server..................................................................5-16 5.4.4 Modifying the IP Address of the SC on the T5220 Server..................................................................5-18 5.4.5 Changing the IP Address of the XSCF on the M4000/M5000 Server.................................................5-19 5.5 Modifying the IP Address of the Disk Array................................................................................................5-21 5.5.1 Modifying the IP Address of the 3320 Disk Array..............................................................................5-22 5.5.2 Changing the IP Address of the S3X00 Series Disk Array (Serial Port Mode)...................................5-23 5.5.3 Changing the IP Address of the 6140 Disk Array (Serial Port Mode).................................................5-28 5.5.4 Changing the IP Address of the S2600 Disk Array (Serial Port Mode)..............................................5-32
6 Managing the M2000 Clients...................................................................................................6-1

6.1 Managing Files and Disks on M2000 Clients.................................................................................................6-2 6.1.1 Introduction to the M2000 Client File System.......................................................................................6-2 6.1.2 Clearing the Disk Space of an M2000 Client.........................................................................................6-4 6.2 Monitoring the Login Status of the M2000 Clients........................................................................................ 6-5 6.3 Setting the Number of Clients Accessible on a PC.........................................................................................6-5 6.4 Setting the Time Information on the M2000 Client........................................................................................6-6 6.4.1 Modifying the Date, Time, and Time Zone on the M2000 Client.........................................................6-7 6.4.2 Setting the NTP Service on the M2000 Client.......................................................................................6-7
7 Managing the M2000 Users (HA)............................................................................................7-1

7.1 Types of M2000 Users....................................................................................................................................7-2 7.1.1 Introduction to Solaris Users..................................................................................................................7-2 7.1.2 Introduction to Sybase Users..................................................................................................................7-4 7.1.3 NE Users................................................................................................................................................ 7-4 7.1.4 Principles of NM User Authorization.................................................................................................... 7-6 7.1.5 Principles of NE User Authorization..................................................................................................... 7-7 7.2 Managing Solaris Users (HA).........................................................................................................................7-7 7.2.1 Introduction to Solaris Users..................................................................................................................7-8 7.2.2 Changing the Password of User root...................................................................................................7-10 7.2.3 Changing the Password of User dbuser..............................................................................................7-11 7.2.4 Changing the Password of User omcuser............................................................................................7-11 7.2.5 Changing the Password of the User ftpuser (HA)................................................................................7-12 7.2.6 Creating a Solaris User.........................................................................................................................7-14 7.2.7 Deleting a Solaris User.........................................................................................................................7-15 7.3 Managing Sybase Users (HA).......................................................................................................................7-16 7.3.1 Introduction to Sybase Users................................................................................................................7-16 7.3.2 Changing the Password of the User sa (HA)........................................................................................7-16 7.4 Managing OM Users.....................................................................................................................................7-19
8 Managing OSS System (HA)...................................................................................................8-1

8.1 Monitoring the M2000 Server (HA)............................................................................................................... 8-3 8.1.1 Refreshing the Monitoring Information.................................................................................................8-4 Issue 03 (2010-08-31) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xi
Contents
HA System Administrator Guide (Sun, S10) 8.1.2 Checking the CPU and Memory Usage Information About the M2000 Server (HA)...........................8-4 8.1.3 Checking the Disk Usage Information About the M2000 Server Through the M2000 Client (HA) .........................................................................................................................................................................8-5 8.1.4 Checking the Database Usage Information About the M2000 Server Through the M2000 Client.......8-7 8.1.5 Checking the M2000 Services................................................................................................................8-8 8.1.6 Checking the Status of the M2000 Processes.........................................................................................8-9 8.1.7 Viewing the Information about M2000 Server Components...............................................................8-10 8.1.8 Saving the Monitoring Information......................................................................................................8-10 8.1.9 Setting Alarm Thresholds for the M2000............................................................................................8-10
8.2 Querying the System Logs of the M2000.....................................................................................................8-18 8.3 Collecting NM Log Files...............................................................................................................................8-19 8.4 Querying NE Subareas..................................................................................................................................8-21 8.5 Managing the M2000 License.......................................................................................................................8-21 8.5.1 Querying the M2000 License...............................................................................................................8-22 8.5.2 Updating the M2000 License...............................................................................................................8-22 8.6 Check OMC status........................................................................................................................................8-22 8.7 Integrated Task Management........................................................................................................................8-23 8.7.1 Overview of Integrated Task Management..........................................................................................8-24 8.7.2 Customizing the Interface for Managing Timing Tasks......................................................................8-39 8.7.3 Creating a User Timing Task...............................................................................................................8-40 8.7.4 Modifying a Timing Task....................................................................................................................8-41 8.7.5 Managing Timing Tasks.......................................................................................................................8-42 8.7.6 Browsing the Information of Timing Tasks.........................................................................................8-45 8.7.7 Viewing the Task Execution................................................................................................................8-46 8.7.8 Viewing the Task History....................................................................................................................8-46 8.7.9 Downloading Task Execution Tasks....................................................................................................8-47 8.7.10 Downloading Result Files..................................................................................................................8-47 8.8 Reference of the OSS Management GUI......................................................................................................8-50 8.8.1 Interface Description: Managing Scheduled Tasks..............................................................................8-53 8.8.2 Interface Description: M2000 Log Information Collector...................................................................8-55 8.8.3 Parameters for the NE Partitioning Information..................................................................................8-55 8.8.4 Parameters for Querying the M2000 License ......................................................................................8-56 8.8.5 Parameters for Setting Monitoring Parameters of the M2000 Server..................................................8-57 8.8.6 Parameters for Monitoring the M2000 Server Service Status..............................................................8-64 8.8.7 Parameters for Monitoring the M2000 Server Process Status.............................................................8-65 8.8.8 Parameters for Monitoring the M2000 Server Hard Disk Status.........................................................8-66 8.8.9 Parameters for Monitoring the M2000 Server Database Status...........................................................8-66 8.8.10 Parameters for Monitoring the M2000 Server Status.........................................................................8-67 8.8.11 Parameters for Viewing the Information about M2000 Server Components.....................................8-68 8.8.12 Parameters for Setting Task Filter Conditions...................................................................................8-69 8.8.13 Parameters for Setting the Common Information for Creating or Replicating a Task.......................8-70 8.8.14 Parameters for Setting Common Parameters for Timing Tasks.........................................................8-71 8.8.15 Parameters for Setting the Time When a Periodic Task Is Created or Copied..................................8-73 xii Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 03 (2010-08-31)
Contents
8.8.16 Parameters for Setting the Time When a One-Time Task Is Created or Copied...............................8-74 8.8.17 Parameters for Modifying a Database Capacity Management Task..................................................8-75 8.8.18 Parameters for Modifying the Export of Performance Data..............................................................8-79 8.8.19 Parameters for Modifying a Configuration Data Export Task...........................................................8-81 8.8.20 Parameters for Modifying the Export of NE Logs.............................................................................8-83 8.8.21 Parameters for Modifying the Export of Inventory Data...................................................................8-84 8.8.22 Parameters for Modifying an Alarm/Event Log Export Task............................................................8-85 8.8.23 Parameters for Modifying the Export of M2000 Logs.......................................................................8-86 8.8.24 Parameters for Modifying NE Basic Information Export Task.........................................................8-87 8.8.25 Parameters for Modifying the Synchronization of NE Configuration Data ......................................8-88 8.8.26 Parameters for Modifying the Synchronization of Inventory Data....................................................8-88 8.8.27 Parameter Description: Modifying a Data Backup Task of the M2000.............................................8-89 8.8.28 Parameters for Creating/Modifying/Copying NE Backup.................................................................8-89 8.8.29 Parameters for Creating/Modifying/Copying MML Command Script..............................................8-90 8.8.30 Parameters for Creating, Modifying, or Copying a Configuration Report Export Task....................8-92 8.8.31 Parameter Description: Creating, Viewing, or Modifying a Scheduled Report Task........................8-93 8.8.32 Parameters for Creating/Modifying/Copying Scheduled NodeB License Allocation Tasks.............8-97 8.8.33 Parameters for Creating/Modifying/Copying Scheduled BSC or RNC License Allocation Tasks .......................................................................................................................................................................8-98 8.8.34 Parameters for Creating/Modifying/Copying a Task for Testing BTS Cabinet-Top Power..............8-99 8.8.35 Parameters for Creating/Modifying/Copying an RSSI Test Task......................................................8-99 8.8.36 Parameters for Creating/Modifying/Copying Software Download.................................................. 8-100 8.8.37 Parameters for Creating/Modifying/Copying a Dual-Homing Auto Consistency Check Task.......8-100 8.8.38 Parameters for Creating/Modifying/Copying an HSL Script Task..................................................8-101 8.8.39 Parameters for Creating/Modifying/Copying the Export of NE Upgrade Log................................8-102 8.8.40 Parameters for Creating/Modifying/Copying a CME Upload Task.................................................8-102 8.8.41 Parameters for Creating/Modifying/Copying Cell Parameters Compare Task................................8-103 8.8.42 Parameters for Creating/Modifying/Copying Cell Consistency Check Task..................................8-103 8.8.43 Parameters for Creating/Modifying/Copying a CME Current Area Export Task............................8-104 8.8.44 Parameters for Setting Time of Timing Tasks.................................................................................8-104 8.8.45 Parameters for Selecting Objects for OMC Check..........................................................................8-105 8.8.46 Parameters for Collecting NM Logs Parameters..............................................................................8-106
9 Managing the M2000 Processes and Services (HA).............................................................9-1

9.1 Introduction to M2000 Processes and Services...............................................................................................9-2 9.1.1 3rdTool_agent Process...........................................................................................................................9-5 9.1.2 adn_agent Process..................................................................................................................................9-5 9.1.3 adss_agent Process.................................................................................................................................9-6 9.1.4 antenna_agent Process............................................................................................................................9-6 9.1.5 ce_agent Process....................................................................................................................................9-6 9.1.6 cmdc_agent Process...............................................................................................................................9-6 9.1.7 cmengine_agent Process........................................................................................................................9-6 9.1.8 cmeserver_agent Process........................................................................................................................9-7 Issue 03 (2010-08-31) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xiii
Contents
HA System Administrator Guide (Sun, S10) 9.1.9 cmexp_agent Process.............................................................................................................................9-7 9.1.10 cmserver_agent Process.......................................................................................................................9-7 9.1.11 cnnhc_agent Process............................................................................................................................9-8 9.1.12 corba_agent Process.............................................................................................................................9-8 9.1.13 cpm_agent Process...............................................................................................................................9-8 9.1.14 devdoc_agent Process..........................................................................................................................9-8 9.1.15 dsXXXX agent Process..........................................................................................................................9-8 9.1.16 eam_agent Process...............................................................................................................................9-9 9.1.17 fars_agent Process................................................................................................................................9-9 9.1.18 fmnotify_agent Process........................................................................................................................9-9 9.1.19 FMPreServiceXXXX_agent Process...................................................................................................9-10 9.1.20 fnlicense_agent Process......................................................................................................................9-10 9.1.21 glmssyn_agent Process.......................................................................................................................9-10 9.1.22 ifms_agent Process.............................................................................................................................9-10 9.1.23 ipqdt_agent Process............................................................................................................................9-11 9.1.24 ipm_agent Process..............................................................................................................................9-11 9.1.25 irp_agent Process................................................................................................................................9-11 9.1.26 itm_agent Process...............................................................................................................................9-12 9.1.27 lcsserver_agent Process......................................................................................................................9-12 9.1.28 lic_agent Process................................................................................................................................9-13 9.1.29 log_agent Process...............................................................................................................................9-13 9.1.30 necomm_agent Process......................................................................................................................9-13 9.1.31 maintain_agent Process......................................................................................................................9-13 9.1.32 manager_agent Process......................................................................................................................9-14 9.1.33 medXXXX_agent Process................................................................................................................... 9-14 9.1.34 nelicense_agent Process.....................................................................................................................9-14 9.1.35 neuser_agent Process..........................................................................................................................9-14 9.1.36 ngnffs_agent Process..........................................................................................................................9-15 9.1.37 ngnnis_agent Process......................................................................................................................... 9-15 9.1.38 ngnni112_agent Process.....................................................................................................................9-15 9.1.39 ngntestmanage_agent Process............................................................................................................9-15 9.1.40 nhcserver_agent Process.................................................................................................................... 9-15 9.1.41 nicserver_agent Process..................................................................................................................... 9-15 9.1.42 nimserver_agent Process....................................................................................................................9-16 9.1.43 nms_mml_agent Process....................................................................................................................9-16 9.1.44 partition_agent Process...................................................................................................................... 9-16 9.1.45 pm_agent Process...............................................................................................................................9-16 9.1.46 pmexp_agent Process.........................................................................................................................9-17 9.1.47 pmmon_agent Process........................................................................................................................9-17 9.1.48 pmncdXX01_agent Process................................................................................................................9-17 9.1.49 porttrunk_agent Process.....................................................................................................................9-17 9.1.50 proxy_agent Process...........................................................................................................................9-18
xiv
Issue 03 (2010-08-31)
Contents
9.1.51 PRSAssistantService_agent Process..................................................................................................9-18 9.1.52 prsdc_agent Process...........................................................................................................................9-18 9.1.53 prsfs_agent Process............................................................................................................................9-18 9.1.54 prsreport_agent Process......................................................................................................................9-19 9.1.55 prssum_agent Process........................................................................................................................9-19 9.1.56 rn_agent Process.................................................................................................................................9-19 9.1.57 ScriptModuleService_agent Process..................................................................................................9-19 9.1.58 scriptserver_agent Process.................................................................................................................9-19 9.1.59 sm_agent Process...............................................................................................................................9-20 9.1.60 snmp_agent Process...........................................................................................................................9-20 9.1.61 son_agent Process..............................................................................................................................9-20 9.1.62 swm_agent Process............................................................................................................................9-20 9.1.63 threshold_agent Process.....................................................................................................................9-21 9.1.64 uap_agent Process..............................................................................................................................9-21 9.1.65 udpdispatch_agent Process.................................................................................................................9-21 9.1.66 umgupdsvr_agent Process..................................................................................................................9-21 9.1.67 xftpXX01_agent Process.....................................................................................................................9-21 9.1.68 Processes and Services Related to Each Northbound Interface.........................................................9-22 9.1.69 Checking the Status of the M2000 Processes.....................................................................................9-23 9.2 Managing M2000 Services (HA)..................................................................................................................9-24 9.2.1 Checking the M2000 Services..............................................................................................................9-24 9.2.2 Viewing the States of M2000 Services (HA).......................................................................................9-25 9.2.3 Starting the M2000 Services (HA).......................................................................................................9-26 9.2.4 Stopping M2000 Services (HA)...........................................................................................................9-27
10 Managing the M2000 Databases..........................................................................................10-1

10.1 M2000 Database..........................................................................................................................................10-2 10.1.1 cmedb Database..................................................................................................................................10-3 10.1.2 farsdb Database..................................................................................................................................10-4 10.1.3 fmdb Database....................................................................................................................................10-4 10.1.4 itfndb Database...................................................................................................................................10-5 10.1.5 omcdb Database.................................................................................................................................10-5 10.1.6 omceamdb Database...........................................................................................................................10-7 10.1.7 omclogdb Database............................................................................................................................10-8 10.1.8 omcsmdb Database.............................................................................................................................10-9 10.1.9 omctempdb Database.......................................................................................................................10-10 10.1.10 omctmdb Database.........................................................................................................................10-10 10.1.11 pmcomdb Database........................................................................................................................10-11 10.1.12 pmdb Database...............................................................................................................................10-13 10.1.13 sumdb Database..............................................................................................................................10-14 10.1.14 swmdb Database.............................................................................................................................10-17 10.2 Viewing the States of M2000 Databases ..................................................................................................10-18
Issue 03 (2010-08-31)
xv
Contents
HA System Administrator Guide (Sun, S10) 10.2.1 Checking the Database Usage Information About the M2000 Server Through the M2000 Client .....................................................................................................................................................................10-18 10.2.2 Viewing the Database Usage of the M2000 Server Using Sybase Commands...............................10-19
10.3 Clearing M2000 Databases.......................................................................................................................10-21 10.4 Backing Up M2000 Databases..................................................................................................................10-23
11 Managing the M2000 Files and Disks (HA)......................................................................11-1

11.1 Managing Files and Disks on M2000 Clients.............................................................................................11-2 11.1.1 Introduction to the M2000 Client File System...................................................................................11-2 11.1.2 Clearing the Disk Space of an M2000 Client.....................................................................................11-4 11.2 Managing Files and Disks on the M2000 Server (HA)...............................................................................11-5 11.2.1 Introduction to the M2000 Server File System (HA).........................................................................11-5 11.2.2 Viewing the Disk Usage of the M2000 Server Using Solaris Commands.......................................11-14 11.2.3 Clearing the Disk Space of the M2000 Server.................................................................................11-14
12 Backing Up and Restoring the M2000 (HA)......................................................................12-1

12.1 M2000 Backup and Restore Solutions........................................................................................................12-2 12.1.1 Backup of M2000 Dynamic Data.......................................................................................................12-2 12.1.2 Policies of M2000 Data Backup.........................................................................................................12-4 12.1.3 Scenarios of M2000 Data Restoration............................................................................................... 12-4 12.2 Backing Up and Restoring M2000 Dynamic Data (HA)............................................................................12-5 12.2.1 Setting a Storage Device of Backup Data Through the Client (HA)................................................. 12-5 12.2.2 Periodically Backing Up the M2000 Dynamic Data (HA)................................................................ 12-7 12.2.3 Manually Backing Up the M2000 Dynamic Data (HA)....................................................................12-9 12.2.4 Restoring the M2000 Dynamic Data (HA)......................................................................................12-10
13 M2000 Routine Maintenance (HA).....................................................................................13-1

13.1 M2000 Routine Maintenance Items (HA)...................................................................................................13-2 13.2 Daily Maintenance Operations (HA).......................................................................................................... 13-4 13.2.1 Checking the Cluster Status (HA)......................................................................................................13-6 13.2.2 Checking the Status of Performance Measurement........................................................................... 13-7 13.2.3 Checking the Missing Performance Result........................................................................................13-7 13.2.4 Checking the Alarm Reception..........................................................................................................13-8 13.2.5 Checking the NMS Connection..........................................................................................................13-8 13.2.6 Checking the Functionality of Alarm Box.........................................................................................13-8 13.2.7 Checking the Owner of the M2000 File System................................................................................13-9 13.2.8 Check OMC Alarms/Events...............................................................................................................13-9 13.2.9 Checking Connections Between the M2000 and NEs.....................................................................13-13 13.2.10 Checking M2000 Logs...................................................................................................................13-13 13.2.11 Checking the Error Log of the Solaris...........................................................................................13-14 13.2.12 Checking the Disk Usage of the M2000 Server.............................................................................13-15 13.2.13 Checking the States of M2000 Databases......................................................................................13-15 13.2.14 Checking the States of M2000 Services.........................................................................................13-16 13.2.15 Checking the Core Files on the Server...........................................................................................13-16 13.2.16 Checking the Hardware of the M2000 Server................................................................................13-17 xvi Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 03 (2010-08-31)
Contents
13.2.17 Checking the SMC Collection Results...........................................................................................13-17 13.3 Weekly Maintenance Operations (HA).....................................................................................................13-18 13.3.1 Checking the Configuration of Alarm Timing.................................................................................13-19 13.3.2 Checking the Configuration of Automatic Log Dump.....................................................................13-19 13.3.3 Checking the Synchronization Time of NE Log..............................................................................13-21 13.3.4 Checking the Configuration of the File Server ...............................................................................13-21 13.3.5 Checking the Configuration of System Backup...............................................................................13-22 13.3.6 Checking the Configuration of System Monitoring.........................................................................13-22 13.3.7 Checking the Synchronization Time of NE Configuration..............................................................13-30 13.3.8 Checking the Threshold of Network Management Capability.........................................................13-31 13.3.9 Checking the Status of the M2000 Routes.......................................................................................13-31 13.3.10 Backing Up the M2000..................................................................................................................13-31 13.3.11 Checking the Time of the M2000 Server (HA)..............................................................................13-33 13.3.12 Checking the States of M2000 Disks.............................................................................................13-34 13.4 Monthly Maintenance Operations (HA)...................................................................................................13-35 13.4.1 Checking the Power Supply of the M2000 Server...........................................................................13-35 13.4.2 Checking the Peripherals of the M2000 Server...............................................................................13-36 13.4.3 Checking the Timeout for Stopping the M2000 Application Resources.........................................13-37 13.4.4 Checking the Trust Between Two Servers in an HA System..........................................................13-38 13.4.5 Checking the Version of the Sun Cluster Software..........................................................................13-39 13.4.6 Checking the Global Devices of an HA System..............................................................................13-39 13.4.7 Checking the Logical Host of an HA System..................................................................................13-40 13.4.8 Checking the Right and Owner of the /opt/SUNWscsyb/bin/sybase_stop_servers File..................13-40 13.4.9 Checking the Front Panel of a Disk Array.......................................................................................13-41 13.4.10 Querying the M2000 License.........................................................................................................13-41
14 M2000 Emergency Maintenance (HA)................................................................................14-1

14.1 Guide to Emergency Maintenance of the M2000 Server............................................................................14-2 14.2 Guide to Emergency Maintenance of the M2000 Client.............................................................................14-2 14.3 Guide to Emergency Maintenance of the M2000 Server in Case of Power Failure (HA)..........................14-2 14.3.1 Troubleshooting: Failure to Start the Solaris Due to Loss of System Files.......................................14-3 14.3.2 Troubleshooting: System Switched into the Maintenance Mode and Prompting You to Run fsck Manually........................................................................................................................................................14-4 14.3.3 Troubleshooting: Loss of Database Device Files After the Restoration of the File System (HA) .......................................................................................................................................................................14-5 14.3.4 Troubleshooting: Failure to Restore the Database Though the File System Is Intact (HA)..............14-5
15 Troubleshooting the M2000.................................................................................................15-1

15.1 Procedure for Troubleshooting the M2000 ................................................................................................15-2 15.2 Collecting M2000 Site and Software Information......................................................................................15-3 15.2.1 Collecting the M2000 Site Information.............................................................................................15-3 15.2.2 Collecting the Time of M2000 Fault Occurrence..............................................................................15-4 15.2.3 Collecting the IP Address of the M2000 Server................................................................................15-4 15.2.4 Collecting the Solaris Version............................................................................................................15-4 Issue 03 (2010-08-31) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xvii
Contents
HA System Administrator Guide (Sun, S10) 15.2.5 Collecting Sybase Version Information.............................................................................................15-5 15.2.6 Obtaining the Version Information About the M2000.......................................................................15-6
15.3 Collecting Fault Data Using the Log Information Collector.......................................................................15-7
16 FAQs (HA, Sun)......................................................................................................................16-1

16.1 About Solaris (HA, Sun).............................................................................................................................16-2 16.1.1 How Do I Log In to the M2000 Server as User root Through Telnet................................................16-3 16.1.2 How to Log In the M2000 Server as the root User Through FTP.....................................................16-4 16.1.3 How to Check the Status of the Tape Drive.......................................................................................16-5 16.1.4 How Should I Select a Tape Drive.....................................................................................................16-6 16.1.5 How to View the Hardware Settings of the M2000 Server................................................................16-7 16.1.6 How to Check the Device Status of the M2000 Server......................................................................16-7 16.1.7 Why Unable to Enter the Domain Console of Fire E4900...............................................................16-11 16.1.8 How to Modify the Port Number of the FTP Server........................................................................16-12 16.1.9 How to Query the Time Zone Name................................................................................................16-12 16.1.10 How Should I Stop the NTP Service on the M2000 Server (HA).................................................16-14 16.1.11 How Do I Change the IP Address of the S3X00 Disk Array (Command Mode)..........................16-15 16.1.12 How Should I Change the IP Address of the 6140 Disk Array (Command Mode).......................16-17 16.1.13 How Do I Change the IP Address of the S2600 Disk Array (Command Mode)...........................16-22 16.1.14 What Should I Do When the CD-ROM Drive Cannot Read the CD-ROM..................................16-24 16.1.15 How to Handle the corrupt label - wrong magic number Message...........................................16-25 16.1.16 What Should I Do When the Server Disk Space Is Insufficient....................................................16-26 16.1.17 How to Configuring the Monitoring Function of the S2600 Disk Array.......................................16-27 16.1.18 How Should I Configure the Monitoring Function for the S3000 Series Disk Arrays..................16-29 16.1.19 How Should I Uninstall the OceanStor Monitoring Software.......................................................16-33 16.1.20 How Should I Check the Running Status of the FTP Service on the M2000 Server.....................16-33 16.1.21 How Should I Start the FTP Service on the M2000 Server...........................................................16-34 16.1.22 How Should I Check the Running Status of the SFTP Service on the M2000 Server...................16-34 16.1.23 How Should I Start the SFTP Service on the M2000 Server.........................................................16-35 16.1.24 How Do I Log In to the Server in SSH Mode................................................................................16-35 16.2 About Sybase (HA, Sun)...........................................................................................................................16-37 16.2.1 How Do I Check Whether the Sybase Is Started..............................................................................16-38 16.2.2 How to Start the Sybase (HA, Sun)..................................................................................................16-38 16.2.3 How to Stop the Sybase (HA, Sun)..................................................................................................16-39 16.2.4 How to View the Name of the Sybase Server..................................................................................16-39 16.2.5 How to Handle Database Alarms.....................................................................................................16-39 16.2.6 How to View Database Deadlock Information................................................................................16-40 16.2.7 Why the Sybase Is Not Started After the Server Restarted..............................................................16-42 16.2.8 Why Is the Sybase Not Started After Run svc_profile.sh................................................................16-43 16.2.9 Why the Sybase Backup Database Abort.........................................................................................16-44 16.2.10 What Should I Do When the Database Cannot Be Started Properly..............................................16-44 16.2.11 What Should I Do When the Client Is Disconnected Due to Damaged System Tables in the Database (HA)............................................................................................................................................................16-45 xviii Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 03 (2010-08-31)
Contents
16.2.12 What Should I Do When the Number of Database Connections Is Insufficient............................16-47 16.2.13 How to Handle the '/export/home/sybdev/master.dat' already in use Message........................16-48 16.3 About Server Software (HA, Sun)............................................................................................................16-49 16.3.1 Why M2000 Services Restart Abnormally (HA, Sun).....................................................................16-50 16.3.2 Why M2000 Services Stop Abnormally (HA, Sun).........................................................................16-51 16.3.3 Why M2000 Services Fail to Start After the Server Restarts (HA, Sun).........................................16-51 16.3.4 How Do I Copy the Backup Dynamic Data from a Hard Disk to a Tape (HA, Sun)......................16-52 16.3.5 How Do I Copy the Backup Dynamic Data from a Tape to a Hard Disk (HA, Sun)......................16-53 16.3.6 How Do I Verify the Dynamic Data Backed Up on a Tape.............................................................16-54 16.3.7 How to Set the M2000 Administration Console as the Intermediary-Layer NTP Server (In Encryption Mode)..........................................................................................................................................................16-55 16.3.8 How Do I Check the Running Status of the NTP Services on the Administration Console (In Encryption Mode)..........................................................................................................................................................16-57 16.3.9 How to Set the M2000 Server as the NTP Client (HA, in Encryption Mode).................................16-58 16.3.10 How to Check the Running Status of the NTP Service on the M2000 Server (HA, in Encryption Mode) .....................................................................................................................................................................16-61 16.3.11 How Should I Handle an Incremental Backup Failure...................................................................16-61 16.3.12 How Should I Periodically Monitoring the CPU, Memory, and Disk...........................................16-62 16.3.13 How Should I Power On the T5220 Server Through the Serial Port of the SC.............................16-63
Issue 03 (2010-08-31)
xix
Figures
Figures
Figure 1-1 Logical architecture of the M2000 HA system...................................................................................1-3 Figure 1-2 Software architecture of the HA system.............................................................................................1-4 Figure 2-1 Netra 240 server..................................................................................................................................2-3 Figure 2-2 3320 disk array...................................................................................................................................2-3 Figure 2-3 3320 disk array...................................................................................................................................2-5 Figure 2-4 Closing the 3320 disk array................................................................................................................2-6 Figure 2-5 Netra 240 server..................................................................................................................................2-7 Figure 2-6 6140 disk array...................................................................................................................................2-8 Figure 2-7 V890 server.........................................................................................................................................2-9 Figure 2-8 Rotary switch at the position Force off............................................................................................ 2-10 Figure 2-9 6140 disk array (I)............................................................................................................................ 2-11 Figure 2-10 6140 disk array (II).........................................................................................................................2-11 Figure 2-11 Netra 240 server..............................................................................................................................2-13 Figure 2-12 6140 disk array............................................................................................................................... 2-14 Figure 2-13 E4900 server...................................................................................................................................2-15 Figure 2-14 6140 disk array (I).......................................................................................................................... 2-17 Figure 2-15 6140 disk array (II).........................................................................................................................2-18 Figure 2-16 S2600 disk array.............................................................................................................................2-19 Figure 2-17 S3200 disk array.............................................................................................................................2-20 Figure 2-18 T5220 server...................................................................................................................................2-21 Figure 2-19 T5220 server...................................................................................................................................2-22 Figure 2-20 Disk array (I).................................................................................................................................. 2-23 Figure 2-21 Disk array (II).................................................................................................................................2-23 Figure 2-22 S2600 disk array.............................................................................................................................2-25 Figure 2-23 S3200 disk array.............................................................................................................................2-25 Figure 2-24 SPARC Enterprise M4000/M5000 front operation panel.............................................................. 2-26 Figure 2-25 Disk array (I).................................................................................................................................. 2-29 Figure 2-26 Disk array (II).................................................................................................................................2-29 Figure 4-1 NTP rationale......................................................................................................................................4-4 Figure 4-2 NTP layered architecture....................................................................................................................4-5 Figure 4-3 Schematic diagram of time synchronization for device A..................................................................4-7 Figure 4-4 Directly connecting device A and the NTP server.............................................................................4-9 Figure 4-5 Networking of device A and the intermediate-layer NTP server.....................................................4-10 Issue 03 (2010-08-31) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xxi
Figures
HA System Administrator Guide (Sun, S10) Figure 4-6 Directly connecting device A to the highest layer NTP server........................................................ 4-11 Figure 4-7 Status of NTP service on node 1......................................................................................................4-24
Figure 4-8 Status of NTP service on node 2......................................................................................................4-25 Figure 5-1 Serial ports of the S3X00..................................................................................................................5-24 Figure 5-2 Checking the port configuration.......................................................................................................5-25 Figure 5-3 Port configuration (I)........................................................................................................................5-26 Figure 5-4 Port configuration (II).......................................................................................................................5-26 Figure 5-5 Port configuration (III).....................................................................................................................5-27 Figure 5-6 Port configuration (IV).....................................................................................................................5-27 Figure 5-7 Serial ports of the 6140 disk array....................................................................................................5-29 Figure 5-8 Serial ports provided by the S2600 disk array..................................................................................5-33 Figure 5-9 Successful connection interface........................................................................................................5-34 Figure 5-10 Successful login dialog box............................................................................................................5-34 Figure 8-1 Server Monitor tab page.....................................................................................................................8-5 Figure 8-2 Hard Disk Monitor tab page...............................................................................................................8-6 Figure 8-3 Database Monitor tab page.................................................................................................................8-7 Figure 8-4 Service Monitor tab page....................................................................................................................8-8 Figure 8-5 Process Monitor tab page...................................................................................................................8-9 Figure 8-6 System Monitor Settings dialog box................................................................................................8-11 Figure 8-7 State transition of a scheduled task...................................................................................................8-39 Figure 8-8 Task Management window...............................................................................................................8-54 Figure 8-9 M2000 Log Information Collector interface....................................................................................8-55 Figure 9-1 Process Monitor tab page.................................................................................................................9-24 Figure 9-2 Service Monitor tab page..................................................................................................................9-25 Figure 10-1 Database Monitor tab page...........................................................................................................10-19 Figure 10-2 Periodic backup............................................................................................................................10-24 Figure 10-3 Periodic backup............................................................................................................................10-25 Figure 12-1 Setting a storage device (I).............................................................................................................12-6 Figure 12-2 Setting a storage device (II)............................................................................................................12-6 Figure 12-3 Periodic backup..............................................................................................................................12-8 Figure 12-4 Periodic backup..............................................................................................................................12-9 Figure 12-5 Manual backup.............................................................................................................................12-10 Figure 13-1 Periodic backup............................................................................................................................13-32 Figure 13-2 Periodic backup............................................................................................................................13-33 Figure 15-1 Log Information Collector dialog box............................................................................................15-8 Figure 16-1 SNMP tab page............................................................................................................................16-31 Figure 16-2 PuTTY Configuration...................................................................................................................16-36 Figure 16-3 PuTTY Security Alert...................................................................................................................16-37
xxii
Issue 03 (2010-08-31)
Tables
Tables
Table 3-1 Factory settings of the Sun Cluster......................................................................................................3-3 Table 5-1 Adding or deleting a route....................................................................................................................5-2 Table 5-2 Correspondence between the previous and new IP addresses..............................................................5-5 Table 5-3 Parameters for the standby controller.................................................................................................5-17 Table 5-4 Parameters for the standby controller.................................................................................................5-18 Table 5-5 Setting properties of the serial port....................................................................................................5-24 Table 5-6 Configuration items of the controller port.........................................................................................5-25 Table 5-7 Setting properties of the serial port....................................................................................................5-30 Table 5-8 Setting the properties of a serial port.................................................................................................5-33 Table 6-1 M2000 client software directory..........................................................................................................6-2 Table 7-1 Solaris user accounts............................................................................................................................7-3 Table 7-2 Privileges of M2000 users....................................................................................................................7-6 Table 7-3 Solaris user accounts............................................................................................................................7-9 Table 8-1 Server Monitor...................................................................................................................................8-12 Table 8-2 Hard Disk Monitor.............................................................................................................................8-14 Table 8-3 Database Monitor...............................................................................................................................8-15 Table 8-4 Service Monitor..................................................................................................................................8-17 Table 8-5 Tasks grouped according to the execution period..............................................................................8-25 Table 8-6 Tasks grouped according to the function...........................................................................................8-25 Table 8-7 Tasks grouped according to the feature..............................................................................................8-29 Table 8-8 Description of system scheduled tasks...............................................................................................8-30 Table 8-9 Description of user scheduled tasks...................................................................................................8-32 Table 8-10 Description of the task description parameters................................................................................8-38 Table 8-11 Allowable operations for different task types..................................................................................8-48 Table 8-12 Description of the Task Management window................................................................................8-54 Table 8-13 Server Monitor.................................................................................................................................8-58 Table 8-14 Hard Disk Monitor...........................................................................................................................8-60 Table 8-15 Database Monitor.............................................................................................................................8-61 Table 8-16 Service Monitor................................................................................................................................8-63 Table 8-17 Parameters of Alarm/Event Log Dump Tasks.................................................................................8-75 Table 8-18 Parameters of Performance Data Tasks...........................................................................................8-76 Table 8-19 Parameters of NE Log Tasks............................................................................................................8-78 Table 8-20 Parameters of NM Log Dump Tasks...............................................................................................8-78 Issue 03 (2010-08-31) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. xxiii
Tables
HA System Administrator Guide (Sun, S10) Table 8-21 Description of extended parameters.................................................................................................8-79 Table 8-22 Extended parameters of NIC Configuration Data Export tasks...................................................8-82 Table 8-23 Extended parameters of Configuration Data Export tasks...........................................................8-82 Table 8-24 Descriptions of extended parameters...............................................................................................8-83 Table 8-25 Extended parameters........................................................................................................................8-85 Table 8-26 Descriptions of extended parameters...............................................................................................8-86 Table 8-27 Extended Parameters........................................................................................................................8-89 Table 8-28 Predefined macros............................................................................................................................8-94 Table 8-29 Description of extended parameters...............................................................................................8-102 Table 8-30 Descriptions of parameters for setting timing task time................................................................ 8-105 Table 9-1 Relations between northbound interfaces and their corresponding processes and services..............9-22 Table 10-1 Names and functions of tables in the cmedb database.....................................................................10-3 Table 10-2 Tables of the farsdb database and the corresponding functions.......................................................10-4 Table 10-3 Tables of the fmdb database and the corresponding functions........................................................10-4 Table 10-4 Tables of the itfndb database and the corresponding functions.......................................................10-5 Table 10-5 Names and functions of tables in the omcdb database.....................................................................10-6 Table 10-6 Name and function of each table in the omceamdb database..........................................................10-8 Table 10-7 Names and functions of the tables in the omclogdb database..........................................................10-9 Table 10-8 Tables of the omcsmdb database and the corresponding functions.................................................10-9 Table 10-9 Name and function of each table in the omctempdb database.......................................................10-10 Table 10-10 Names and functions of the tables in the omctmdb database.......................................................10-10 Table 10-11 Counter information tables in the pmcomdb database and the corresponding functions.............10-11 Table 10-12 Template information tables in the pmcomdb database and the corresponding functions.......... 10-12 Table 10-13 Function subsets and period tables in the pmcomdb database and their functions......................10-13 Table 10-14 Template tables in the pmdb database and their functions...........................................................10-14 Table 10-15 Function subset tables and period tables in the pmdb database and the corresponding functions ...........................................................................................................................................................................10-14 Table 10-16 Name and function of each object type information table in the sumdb database.......................10-14 Table 10-17 Name and function of each system setting information table in the sumdb database..................10-15 Table 10-18 Name and function of each report information table in the sumdb database...............................10-16 Table 10-19 Name and function of each performance result table in the sumdb database..............................10-17 Table 10-20 Tables of the swmdb database and the corresponding functions.................................................10-18 Table 11-1 M2000 client software directory......................................................................................................11-2 Table 11-2 Directories for storing the M2000 server software..........................................................................11-6 Table 11-3 Planning of the server disk partitions (HA, V890)..........................................................................11-9 Table 11-4 Planning for the 6140 disk array......................................................................................................11-9 Table 11-5 Planning of the server disk partitions (HA, E4900).......................................................................11-10 Table 11-6 Planning for the 6140 disk array....................................................................................................11-10 Table 11-7 Disk partition planning of the T5220 server..................................................................................11-11 Table 11-8 Planning for the S3100 disk array..................................................................................................11-11 Table 11-9 Planning for the S2600 disk array..................................................................................................11-12 Table 11-10 Disk partition planning of the M4000/M5000 server.................................................................. 11-12 Table 11-11 Planning for the S3200/6140 disk array.......................................................................................11-13
xxiv
Issue 03 (2010-08-31)
Tables
Table 11-12 Planning for the S2600 disk array................................................................................................11-13 Table 12-1 Introduction to dynamic data backup...............................................................................................12-2 Table 13-1 List of maintenance items................................................................................................................13-2 Table 13-2 Result of the scstat command..........................................................................................................13-6 Table 13-3 Alarms that need to be handled immediately.................................................................................13-10 Table 13-4 Alarms that need to be handled within one day.............................................................................13-11 Table 13-5 Alarms to be focused on during network expansion......................................................................13-11 Table 13-6 Alarms about malicious operations................................................................................................13-11 Table 13-7 Events that need to be handled immediately..................................................................................13-12 Table 13-8 Events that need to be handled within one day..............................................................................13-12 Table 13-9 Events that need to be focused on during network expansion.......................................................13-12 Table 13-10 Server Monitor.............................................................................................................................13-24 Table 13-11 Hard Disk Monitor.......................................................................................................................13-26 Table 13-12 Database Monitor.........................................................................................................................13-27 Table 13-13 Service Monitor............................................................................................................................13-29 Table 16-1 Tape drive status..............................................................................................................................16-5 Table 16-2 Checking the server configuration...................................................................................................16-7 Table 16-3 Commands for checking the device status.......................................................................................16-8 Table 16-4 Example of the matching table between countries and time zone names......................................16-13 Table 16-5 Setting the properties of the serial port..........................................................................................16-19
Issue 03 (2010-08-31)
xxv
1 M2000 High Availability System
M2000 High Availability System
About This Chapter

This chapter describes the features, working principles, logical architecture, and software architecture of the M2000 HA system. 1.1 Features and Working Principles of the HA System This section describes the features and working principles of the HA system. 1.2 Logical Architecture of the HA System This section describes the logical architecture of the HA system. 1.3 Software Architecture of the HA System This section describes the software architecture of the HA system.
Issue 03 (2010-08-31)
1-1
1.1 Features and Working Principles of the HA System

This section describes the features and working principles of the HA system.
Features
CAUTION
The active and standby nodes stand for the active and standby servers respectively. In the HA system, the Sun Cluster manages the active and standby nodes to provide a secure and reliable network management system. The HA system has the following features:
l l
Reduces the risk of system breakdown caused by software or hardware faults Supports online maintenance, during which the ongoing services are not disrupted
The high availability of the HA system is achieved through the combination of software and hardware. Redundant interconnected clusters, memory storage, and public network prevent single-point failures. The HA system continuously monitors the hardware and software. The HA system switches between the active and standby servers or restarts the network management system when a fault occurs.
Working Principles
The M2000 HA system has two connected Sun servers that are managed by the Sun Cluster. One is the active server and the other is the standby server. The system switches to the standby server when the active server is faulty. The Solaris, Cluster, Volume Manager, Sybase, and M2000 applications run on the active server, where the Solaris, Cluster, and Volume Manager also run on the standby server.
NOTE
l l
The M2000 HA system performs the active/standby server switchover. The time required for the active/standby server switchover is equal to the sum of the following time:
l l l l l l
Time for stopping the M2000 on the active server Time for stopping the Sybase on the active server Time for stopping the disk array and the other resources on the active server Time for starting the disk array and the other resources on the standby server Time for starting the Sybase on the standby server Time for starting the M2000 on the standby server
The time required for the active/standby server switchover is determined by the sum of the time for stopping the M2000 services and the time for starting the M2000 services.
1-2
Issue 03 (2010-08-31)
1.2 Logical Architecture of the HA System

This section describes the logical architecture of the HA system. Figure 1-1 shows the logical architecture of the M2000 HA system. Figure 1-1 Logical architecture of the M2000 HA system
Active and standby servers: the servers of the M2000 . They operate the M2000 server application and NE mediation software. The two servers are monitored and switched over by the SUN Cluster. Disk arrays: protect the data of active and standby servers. They also synchronize the data on the two servers. Cluster console: provides single-point management for the Cluster and the databases. It handles faults occurring in the Cluster.
1.3 Software Architecture of the HA System

This section describes the software architecture of the HA system. Figure 1-2 shows the software architecture of the HA system. The two servers are installed with the same software. The server that provides services is the active server. The Cluster manages the Sybase, the M2000 server applications, and the disk array installed on the active server.
NOTE
If you log in using a user account of the operating system, you must perform the same operations on the active and standby servers. If you log in using a user account of the Sybase or M2000 , you can operate only on the active server.
Issue 03 (2010-08-31)
1-3
Figure 1-2 Software architecture of the HA system
The HA system requires a physical IP address and a logical IP address.

l l
The physical IP address is set on the Ethernet adapter of the server. The logical IP address is provided by the HA system to the public. It is dynamically assigned by the HA system. The logical IP address is assigned to the active server, which provides services for the public. The client can access only the logical IP address for maintenance in case of not knowing the internal implementation of the HA system.
Configure the same IP address for the active and standby servers during the network configuration. For details, refer to chapter 5 Configuring the IP Address of the M2000 Server (HA).
1-4
Issue 03 (2010-08-31)
2 Powering the M2000 On or Off (HA)
Powering the M2000 On or Off (HA)
About This Chapter

This chapter describes how to power on and power off the M2000 HA system. 2.1 Powering the M2000 On or Off (HA, Netra 240) This section describes how to power on and power off the M2000 HA system when the Netra 240 server is used as the M2000 server. 2.2 Powering the M2000 On or Off (HA, V890) This section describes how to power on and power off the M2000 HA system when the V890 server is used as the M2000 server. 2.3 Powering the M2000 On or Off (HA, E4900) This section describes how to power on and power off the M2000 HA system when the E4900 server is used as the M2000 server. 2.4 Powering the M2000 On or Off (HA, T5220) This section describes how to power on and power off the M2000 HA system when the T5220 server is used as the M2000 server. 2.5 Powering the M2000 On or Off (HA, M4000/M5000) This section describes how to power on and power off the M2000 HA system when the M4000/ M5000 server is used as the M2000 server.
Issue 03 (2010-08-31)
2-1
2.1 Powering the M2000 On or Off (HA, Netra 240)

This section describes how to power on and power off the M2000 HA system when the Netra 240 server is used as the M2000 server. 2.1.1 Powering On the M2000 (HA, Netra 240) This section describes how to power on the M2000 HA system when the Netra 240 minicomputer is used as the M2000 server. 2.1.2 Powering Off the M2000 (HA, Netra 240) This section describes how to power off the M2000 HA system when the Netra 240 minicomputer is used as the M2000 server.
2.1.1 Powering On the M2000 (HA, Netra 240)

This section describes how to power on the M2000 HA system when the Netra 240 minicomputer is used as the M2000 server.
Prerequisite
The M2000 system is already shut down. For details, see2.1.2 Powering Off the M2000 (HA, Netra 240).
Procedure
Step 1 Make preparations for powering on the M2000. 1. Ensure that the power switch of each device in the cabinet are in the OFF state. If any power switch is ON, set it to OFF.
NOTE
The devices to be checked include the M2000 server, Netra 240 administration console, KVM, networking devices, and cabinet.
2. 1.
Set the power switch of the cabinet to ON. Turn the rotary switch beside the power supply to the normal position (I), as shown in Figure 2-1.
Step 2 Start the administration console Netra 240.
2-2
Issue 03 (2010-08-31)
Figure 2-1 Netra 240 server
1 4
Power switch Normal position
2 5
Rotary switch Lock position
3 6
Forced turn-off Diagnosis position
2.
Press down the On/Standby button on the power switch of the Netra 240 server to start the M2000 system.
l
If the Solaris operating system is not installed on the M2000 server, the M2000 system is switched to the ok state. If the Solaris operating system is installed on the M2000 server, the M2000 system automatically starts the Solaris operating system. If the M2000 system is switched to the ok state, enter boot to start the Solaris operating system.
3. 4.
Turn the rotary switch to the locked position. Turn on the power of KVM and that of all the network equipment. All the equipment starts automatically after the power is turned on.
Step 3 Power on the two disk arrays 3320. The procedures for powering on two disk arrays are the same. The 3320 disk array is closed, as shown in Figure 2-2. Figure 2-2 3320 disk array
Issue 03 (2010-08-31)
2-3
Step 4 Power on the two Netra 240 servers.
CAUTION
The procedures for powering on the two Netra 240 servers are consistent. Power on the osssvrl first. After three minutes, power on the osssvr-2. 1. 2. Turn the rotary switch beside the power supply to the normal position (I), as shown in Figure 2-1. Press down the On/Standby button on the power switch of the Netra 240 server to start the M2000 system.
l
If the Solaris operating system is not installed on the M2000 server, the system is switched to the ok state. If the Solaris, Cluster, Sybase, and M2000 server applications are installed on the M2000 server, the system automatically starts the Solaris, Cluster, Sybase, and M2000 applications. If the system is switched to the ok state, enter boot to start the operating system. After that, the system automatically starts the Cluster, Sybase, and M2000 applications.
3.
Turn the rotary switch to the locked position.
----End
2.1.2 Powering Off the M2000 (HA, Netra 240)

This section describes how to power off the M2000 HA system when the Netra 240 minicomputer is used as the M2000 server.
Procedure
Step 1 Switch the two Netra 240 servers to the ok state. 1. On the administration console, log in to the two nodes as user root through the corresponding physical IP addresses, and then run the following command, respectively. # sync; sync; sync; sync; sync; sync 2. On node 1 or node 2, switch the system to the ok state. # /usr/cluster/bin/scshutdown -y -g0
NOTE
If the Cluster, Sybase, and M2000 applications are installed in the HA system, the system automatically terminates the M2000 applications and Sybase.
Step 2 Power off the two Netra 240 servers. The procedures for powering off the two Netra 240 servers are the same. 1. 2. Turn the rotary switch to the normal position (I). Press down the On/Standby button on the power switch of the server and then release the button. The system performs a soft switch-off. Wait until the indicator on the front panel is turned off.
2-4
CAUTION
If you press down the On/Standby button and hold for four seconds, the system performs a hard switch-off. The hard switch-off may damage disk drives, thus resulting in data loss. Step 3 Power off the two disk arrays 3320. The procedures for powering off the two disk arrays are the same. The disk array is shown in Figure 2-3. Figure 2-3 3320 disk array
1.
Check whether the I/O activities of the server and the disk array are stopped.
NOTE
a. Wait for two minutes. Check whether the LEDs of the cache on the rear of the controller go out. If all the LEDs go out, you can infer that all the data is written into the disk and that the cache does not hold data. b. Ensure that all the LEDs of all the disk drives at the front of controller stop blinking.
2.
Run the telnet command to log in to the 3320 disk array. telnet IP address of the 3320 disk array
NOTE
If an IP address is not assigned to the 3320 disk array, use the DB9-DB9 serial port cable attached to the 3320 disk array to connect the 3320 disk array and a PC. Log in to the system through the HyperTerminal. After restoring the default settings of the HyperTerminal port, set the baud rate to 38400. If a password is required, keep the password field blank, and then press Enter.
l l
3. 4.
Select Terminal (VT100 Mode), and then press Enter. On the main interface, choose system Functions > Shutdown controller, and then press Enter. The 3320 disk array is closed, as shown in Figure 2-4.
Issue 03 (2010-08-31)
2-5
Figure 2-4 Closing the 3320 disk array
5. 1. 2.
Power off the two groups of power supply and fan modules. Log in to the Netra 240 administration console as user root through SSH mode. Close the Netra 240 administration console. # sync; sync; sync; sync; sync; sync # /usr/sbin/shutdown -y -g0 -i5
Step 4 Power off the Netra 240 administration console.
Step 5 Shut down the power module of the server and the disk array. Step 6 If required, set the power switches of the cabinet and the other devices in the cabinet to OFF. ----End
2.2 Powering the M2000 On or Off (HA, V890)

This section describes how to power on and power off the M2000 HA system when the V890 server is used as the M2000 server. 2.2.1 Powering On the M2000 (HA, V890) This section describes how to power on the M2000 HA system when the V890 minicomputer is used as the M2000 server. 2.2.2 Powering Off the M2000 (HA, V890) This section describes how to power off the M2000 HA system when the V890 minicomputer is used as the M2000 server.
2.2.1 Powering On the M2000 (HA, V890)

This section describes how to power on the M2000 HA system when the V890 minicomputer is used as the M2000 server.
Prerequisite
The M2000 system is already shut down. For details, see2.2.2 Powering Off the M2000 (HA, V890).
2-6 Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 03 (2010-08-31)
Procedure
Step 1 Make preparations for powering on the M2000. 1. Ensure that the power switch of each device in the cabinet are in the OFF state. If any power switch is ON, set it to OFF.
NOTE
The devices to be checked include the M2000 server, disk array, Netra 240 administration console, KVM, networking devices, and cabinet.
2.
Set the power switch of the cabinet to ON.
Step 2 Start the administration console Netra 240. 1. Turn the rotary switch beside the power supply to the normal position (I), as shown in Figure 2-5. Figure 2-5 Netra 240 server
1 4
2 5
3 6
2.
l
3. 4.
Step 3 Power on the two disk arrays 6140. The procedures for powering on the two disk arrays are the same. Set the two power switches on the rear of the 6140 disk array to ON. The disk array is shown in Figure 2-6.
Issue 03 (2010-08-31) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 2-7
CAUTION
Each disk array has two power switches and their directions are opposite.
Figure 2-6 6140 disk array
Off
On
Step 4 Power on the two V890 servers.
CAUTION
The procedures for powering on the two V890 servers are consistent. Power on the osssvr-l first. After three minutes, power on the osssvr-2. 1. Turn the rotary switch to the normal position (I), as shown in Figure 2-7.
2-8
Issue 03 (2010-08-31)
Figure 2-7 V890 server
1 4
2 5
3 6
2.
Press down the power switch of the V890 server.

l
If the Solaris operating system is not installed on the M2000 server, the system is switched to the ok state. If the Solaris, Cluster, Sybase, and M2000 server applications are installed, the system automatically starts them. If the system is switched to the ok state, type boot to start the operating system. Then the system automatically starts the Cluster, Sybase, and M2000 applications.
3.
Turn the rotary switch to the locked position.
----End
2.2.2 Powering Off the M2000 (HA, V890)

This section describes how to power off the M2000 HA system when the V890 minicomputer is used as the M2000 server.
Procedure
Step 1 Switch the two V890 servers to the ok state. 1. On the administration console, log in to the two nodes as user root through the corresponding physical IP addresses, and then run the following command, respectively. # sync; sync; sync; sync; sync; sync 2. On node 1 or node 2, switch the system to the ok state. # /usr/cluster/bin/scshutdown -y -g0

NOTE
Step 2 Power off two V890 servers. The procedures for powering off two V890 servers are the same. 1. 2. Turn the rotary switch beside the power supply to the normal position (I). Press down the power switch of the server and then release the switch. The system performs soft switch-off. Wait until the indicator on the front panel is turned off.
CAUTION
If you press down the power switch and hold it for five seconds, the system performs hard switch-off. Hard switch-off may damage disk drives, thus resulting in data loss. 3. Turn the rotary switch beside the power supply to the position Force off, as shown in Figure 2-8.
Figure 2-8 Rotary switch at the position Force off
1 4
2 5
3 6
Step 3 Power off the two disk arrays 6140. The procedures for powering off the two disk arrays are the same. 1. Wait for two minutes. Check whether the LEDs of the cache on the rear of the controller go out.
2-10
If all the LEDs go out, you can infer that all the data is written into the disk and that the cache does not hold data. Figure 2-9 shows the 6140 disk array. Figure 2-9 6140 disk array (I)
Off
On
2.
Ensure that all the LEDs of all the disk drives at the front of controller stop blinking, as shown in Figure 2-10.
Figure 2-10 6140 disk array (II)
Issue 03 (2010-08-31)
2-11
3.
Set the two power switches at the rear of the controller to OFF.
NOTE
Step 4 Power off the Netra 240 administration console. 1. 2. Log in to the Netra 240 administration console as user root through SSH mode. Close the Netra 240 administration console. # sync; sync; sync; sync; sync; sync # /usr/sbin/shutdown -y -g0 -i5 Step 5 If required, set the power switches of the cabinet and the other devices in the cabinet to OFF. ----End
2.3 Powering the M2000 On or Off (HA, E4900)

This section describes how to power on and power off the M2000 HA system when the E4900 server is used as the M2000 server. 2.3.1 Powering On the M2000 (HA, E4900) This section describes how to power on the M2000 when the E4900 minicomputer is used as the M2000 server. 2.3.2 Powering Off the M2000 (HA, E4900) This section describes how to power off the M2000 HA system with the E4900 servers.
2.3.1 Powering On the M2000 (HA, E4900)

This section describes how to power on the M2000 when the E4900 minicomputer is used as the M2000 server.
Prerequisite
The M2000 system is already shut down. For details, see2.3.2 Powering Off the M2000 (HA, E4900).
Procedure
Step 1 Prepare for powering on the M2000 HA system. 1. Before powering on the M2000, ensure that the power switches of all devices are set to OFF. If any power switch is ON, set it to OFF.
NOTE
The devices to be checked include the M2000 server, disk array, Netra 240 administration console, KVM, networking devices, and cabinet.
2.
Step 2 Start the administration console Netra 240. 1. Turn the rotary switch beside the power supply to the normal position (I), as shown in Figure 2-11.
2-12
Figure 2-11 Netra 240 server
1 4
2 5
3 6
2.
l
3. 4.
Step 3 Power on the 6140 disk array. Set the two power switches on the rear of the 6140 disk array to ON. The disk array is shown in Figure 2-12.
CAUTION
Issue 03 (2010-08-31)
2-13
Figure 2-12 6140 disk array
Off
On
Step 4 Power on the E4900 server,namely, the osssvr-1. 1. Set the power switches of the E4900 server to ON. The E4900 server has three power switches, as shown in Figure 2-13. Currently, only two SCs are powered on. The front indicators of the three power boards remain at steady blue.
2-14
Issue 03 (2010-08-31)
Figure 2-13 E4900 server
Off
On
NOTE
The SC of the E4900 server acts as the console.
2.
Run the telnet logical IP address of the SC of the E4900 server command to log in to the SC and choose 0 to enter the Platform shell. Run the following command to enable the failover function of the SC: sc> setfailover on
NOTE
If the SC of the E4900 server is not configured yet, configure the SC by referring to M2000 HA System Software Initialization Installation Guide (Sun,S10).
3. 4.
Run the poweron all command to switch on all the boards when all the domains are still in the Off state. In Platform shell, run the console -d a command to switch to domain A. Run the setkeyswitch on command to start domain A. This process takes about 20 minutes.
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 2-15
Issue 03 (2010-08-31)

l l
If the system is not installed with the Solaris, it enters the ok status on startup. If the system is installed with the Solaris, Cluster, Sybase, and M2000 software, the system starts them automatically. When the system enters the ok state, type boot to start the Cluster, Sybase, and M2000 .
NOTE
If domain A cannot be accessed because the system is occupied, refer to 16.1.7 Why Unable to Enter the Domain Console of Fire E4900.
Step 5 Repeat Step 4 to start the other E4900 server, namely, the osssvr-2. ----End
2.3.2 Powering Off the M2000 (HA, E4900)

This section describes how to power off the M2000 HA system with the E4900 servers.
Procedure
Step 1 Switch the E4900 HA system to the ok status. 1. On the administration console, log in to the two nodes as user root through the corresponding physical IP addresses, and then run the following command, respectively. # sync; sync; sync; sync; sync; sync 2. On node 1 or node 2, switch the system to the ok state. # /usr/cluster/bin/scshutdown -y -g0
NOTE
Step 2 Switch off the two E4900 servers. The procedures for powering off the two E4900 servers are the same. 1. Run the telnet Server SC IP command to log in to the SC. Select 0 to enter Platform shell.
NOTE
If the server SC is not configured with an IP address, log in to the SC from HyperTerminal. Use the Huawei 04042025 serial port cable to connect the server SC and the PC. The DB-25 connector at one end of the serial port cable is connected to the serial port on the server SC. The DB-9 connector at the other end of the serial port cable is connected to the COM port on the PC. Restore the attributes of the port on the HyperTerminal to default values. This means that baud rate is set to 9600, data bit to 8, parity check to none, stop bit to 1, and data stream control to none.
2.
Run the showkeyswitch command to check which domains are switched on. osssvr-sc0:SC> showkeyswitch
Domain Domain Domain Domain A B C D keyswitch keyswitch keyswitch keyswitch is: is: is: is: on off off off
3.
Run the setkeyswitch -d domainID off command to stop domain A. osssvr-sc0:SC> setkeyswitch -d a off
Powering boards off ...
2-16
Issue 03 (2010-08-31)

NOTE
If some domain is on, run the corresponding command to close the domain.
4.
Run the poweroff all command to stop all systems. All the boards in the system (including the three power boards) except the two SCs are switched off. osssvr-sc0:SC> poweroff all
/N0/SB4: is already off /N0/IB6: is already off /N0/IB8: is already off RP0: is already off RP2: is already off PS0: powered off PS1: powered off PS2: powered off osssvr-sc0:SC>
Step 3 Switch off the 6140 disk array. 1. Wait for two minutes. Check whether the LEDs of the cache on the rear of the controller go out. If all the LEDs go out, you can infer that all the data is written into the disk and that the cache does not hold data. Figure 2-14 shows the 6140 disk array. Figure 2-14 6140 disk array (I)
Off
On
2.
Ensure that all the LEDs of all the disk drives at the front of controller stop blinking, as shown in Figure 2-15.
Issue 03 (2010-08-31)
2-17
Figure 2-15 6140 disk array (II)
3.
NOTE
Step 4 Power off the Netra 240 administration console. 1. 2. Log in to the Netra 240 administration console as user root through SSH mode. Close the Netra 240 administration console. # sync; sync; sync; sync; sync; sync # /usr/sbin/shutdown -y -g0 -i5 Step 5 Set the power switch of the E4900 server to OFF. Set the power switches of the cabinet and other devices in the cabinet to OFF if required. ----End
2.4 Powering the M2000 On or Off (HA, T5220)

This section describes how to power on and power off the M2000 HA system when the T5220 server is used as the M2000 server. 2.4.1 Powering On the M2000 (HA, T5220) This section describes how to power on the M2000 HA system when the M2000 is installed on the T5220 server. 2.4.2 Powering Off the M2000 (HA, T5220)
This section describes how to power off the M2000 HA system when the M2000 is installed on the T5220 server.
2.4.1 Powering On the M2000 (HA, T5220)

This section describes how to power on the M2000 HA system when the M2000 is installed on the T5220 server.
Prerequisite
l l
The M2000 is already powered off. For details, see 2.4.2 Powering Off the M2000 (HA, T5220). The client PC communicates with the server well.
Procedure
Step 1 Prepare for powering on the server. 1. Before powering on the M2000, ensure that the power switches of all devices are set to OFF. If any power switch is ON, set it to OFF.
NOTE
The devices that need to be checked include the M2000 server, disk array, network devices, and cabinet.
2.
Step 2 Power on two disk arrays. The procedures for powering on the two disk arrays are the same. Option S2600 disk array S3100 disk array or 6140 disk array 1. Description Perform Step 2.1. Perform Step 2.2.
Insert the two plugs at the rear of the disk array into the socket, as shown in Figure 2-16. When the hard disk LEDs of all the disk arrays stop blinking, the disk array are started successfully.
CAUTION
l l
Each disk array has two plugs. Ensure that both plugs are inserted into the socket. The S2600 disk array does not have a power switch. After you insert the plug into the socket, the S2600 disk array is automatically powered on.
Figure 2-16 S2600 disk array
Issue 03 (2010-08-31)
2-19
(Disk array with a controller)
(Hard disk frame of the disk array)
2.
Set the two power switches at the rear of the S3200 disk array to ON, as shown in Figure 2-17.
CAUTION
Each disk array has two power switches and their directions are opposite. Figure 2-17 S3200 disk array
OFF
ON
Step 3 Power on two T5220 servers.
CAUTION
The procedures for powering on the two T5220 servers are consistent. Power on the osssvr-l first. After three minutes, power on the osssvr-2. You can also power on the T5220 server through the serial port of the SC. For details, see 16.3.13 How Should I Power On the T5220 Server Through the Serial Port of the SC.
2-20
Issue 03 (2010-08-31)
After set the power switch of the cabinet to ON, waiting for 3 minutes, press the power switch to power on the T5220 server when the LED indicator is lighted, as shown in Figure 2-18. Figure 2-18 T5220 server
If the Solaris operating system is not installed, the system is switched to the ok state after the T5220 server is powered on. If the Solaris, Cluster, Sybase, and the M2000 software are installed, the system starts them automatically. If the server is switched to the ok state, enter boot to start the operating system. Then, the system automatically starts the Cluster software. The Sybase and theM2000 software are also started at the active node.
----End
2.4.2 Powering Off the M2000 (HA, T5220)

This section describes how to power off the M2000 HA system when the M2000 is installed on the T5220 server.
Prerequisite
Log in to the two nodes as user root through SSH mode by using the corresponding physical IP addresses.
Procedure
Step 1 Switch two T5220 servers to the ok state. 1. Run the following commands at the two nodes. # sync; sync; sync; sync; sync; sync 2. Run the following command at either of the nodes to switch the two nodes to the ok state. # /usr/cluster/bin/scshutdown -y -g0
NOTE
Step 2 Power off the two T5220 servers. The procedures for powering off the two T5220 servers are consistent. Press the power switch of the T5220 server and then release. The system performs soft switchoff, as shown in Figure 2-19. Wait until the indicator on the front panel turns off.
CAUTION
If you hold down the power switch for five seconds, the system performs hard switch-off. Hard switch-off may damage disk drives and cause data loss.
Figure 2-19 T5220 server
Step 3 Power off two disk arrays. The procedures for powering off the two disk arrays are consistent. Option S2600 disk array S3100 disk array or 6140 disk array Description Perform Step 3.1 and Step 3.2. Perform Step 3.3 and Step 3.4.
1.
Check whether the I/O activities of the disk arrays are stopped.
NOTE
a. Wait for two minutes. If the LED indicators of all the drives and caches stop blinking, you can infer that the read and write operations of the disk array are stopped. b. Check the cache LED on the controller and determine whether any data on the cache needs to be written to the disk. c. Ensure that the LEDs of all the drive and caches stop blinking.
2. 3.
Remove the two plugs at the rear of the disk array from the socket. Check whether the I/O activities of the disk arrays are stopped. a. Wait for two minutes. If all the LEDs stop blinking, you can infer that all the data is written into the disk and that the cache does not hold data. See Figure 2-20 .
2-22
Issue 03 (2010-08-31)
Figure 2-20 Disk array (I)
1 b.
OFF
ON
Ensure that all the LEDs of all the disk drives at the front of the controller stop blinking. See Figure 2-21. Figure 2-21 Disk array (II)
4.
NOTE
Step 4 If required, set the power switches of the cabinet and the other devices in the cabinet to OFF. ----End
2.5 Powering the M2000 On or Off (HA, M4000/M5000)

This section describes how to power on and power off the M2000 HA system when the M4000/ M5000 server is used as the M2000 server. 2.5.1 Powering On the M2000 (HA, M4000/M5000)
This section describes how to power on the M2000 HA system when the M2000 is installed on the M4000/M5000 server. 2.5.2 Powering Off the M2000 (HA, M4000/M5000) This section describes how to power off the M2000 HA system when the M2000 is installed on the M4000/M5000 server.
2.5.1 Powering On the M2000 (HA, M4000/M5000)

This section describes how to power on the M2000 HA system when the M2000 is installed on the M4000/M5000 server.
Prerequisite
l
The M2000 system is already powered off. For details, see 2.5.2 Powering Off the M2000 (HA, M4000/M5000). The client PC communicates with the server well.
Procedure
Step 1 Prepare for powering on the server. 1. Before powering on the M2000, ensure that the power switches of all devices are set to OFF. If any power switch is ON, set it to OFF.
NOTE
The devices that need to be checked include the M2000 server, disk array, network devices, and cabinet.
2.
Step 2 Power on two disk arrays. The procedures for powering on the two disk arrays are consistent. Option S2600 disk array S3200 disk array or 6140 disk array Description Perform Step 2.1. Perform Step 2.2.
1.
Insert the two plugs at the rear of the disk array into the socket, as shown in Figure 2-22. When the hard disk LEDs of all the disk arrays stop blinking, the disk array are started successfully.
CAUTION
l l
Each disk array has two plugs. Ensure that both plugs are inserted into the socket. The S2600 disk array does not have a power switch. After you insert the plug into the socket, the S2600 disk array is automatically powered on.
2-24
Issue 03 (2010-08-31)
(Disk array with a controller)
(Hard disk frame of the disk array)
2.
Set the two power switches at the rear of the S3200 disk array to ON, as shown in Figure 2-23.
CAUTION
OFF
ON
Step 3 Power on the M2000 server, namely, the osssvr-1.

1.
Enable the PuTTY on the PC. Use the Telnet command to log in to the XSCF of the server.
NOTE
l l l l l
The XSCF of the M4000/M5000 server functions as the system console. Log in to the XSCF of the M4000/M5000 server by using the IP address of the network port 0 of the XSCF. Log in to the http://support.huawei.com to download the PuTTY to the PC. Log in to the XSCF of the M4000/M5000 through the PuTTY. For details, see M2000 HA System Software Initialization Installation Guide (T5220&M4000&M5000, S10). If the XSCF of the M4000/M5000 is not configured yet, configure the XSCF by referring to M2000 HA System Software Initialization Installation Guide (T5220&M4000&M5000, S10).
2. 3.
Log in to the XSCF as user adminuser. Huawei recommends that you use adminuser as the password of the adminuser account. Set the key on the front operation panel of the Huawei server to maintenance position, as shown in Figure 2-24. Figure 2-24 SPARC Enterprise M4000/M5000 front operation panel
1 Power indicator 4 Power supply button 7 Mode switch
2 XSCF state indicator 5 Locked - -
3 Check indicator 6 Maintenance - -
4.
Run the following command to power on domain 0. XSCF> poweron -d 0

DomainIDs to power on: 00 Continue? [y|n] :y
The server automatically starts and performs self-check. This process lasts about 20 minutes. 5.
2-26
Run the following command to switch to area 0:

XSCF> console -d 0 When the system displays the following information, enter y to confirm the information.
Connect to DomainID 0? [y|n] :y l
If the Solaris operating system is not installed on the server, the server switches to the ok state. If the Solaris, Cluster, Sybase, and the M2000 software are installed, the system starts them automatically. If the system is switched to the ok state, enter boot to start the Cluster, Sybase, and the M2000.
6. 7.
Ensure that the LED of available XSCF on the operation panel is in green. On the front panel of the M2000 server, switch the key to the position for Locked.
Step 4 Repeat Step 3 to start the other Huawei server, namely, the osssvr-2. ----End
2.5.2 Powering Off the M2000 (HA, M4000/M5000)

This section describes how to power off the M2000 HA system when the M2000 is installed on the M4000/M5000 server.
Prerequisite
l
Log in to the two nodes as user root through SSH mode by using the corresponding physical IP addresses. The PC correctly communicates with the servers.
Context
l
When the M2000 HA system is installed on the M4000/M5000 server, the S3200 disk array, the 6140 disk array or the S2600 disk array can be configured. The procedures for shutting down the S3200 disk array or the 6140 disk array are consistent. This takes the S3200 disk array as an example to describe the procedures.
Procedure
Step 1 Switch two M4000/M5000 servers to the ok state. 1. Run the following commands at the two nodes. # sync; sync; sync; sync; sync; sync 2. Run the following command at either of the nodes to switch the two nodes to the ok state. # /usr/cluster/bin/scshutdown -y -g0
NOTE
Step 2 Power off two M2000 servers. The procedures for powering off the two M2000 servers are consistent. 1.
Issue 03 (2010-08-31)
Enable the PuTTY on the PC. Use the Telnet command to log in to the XSCF of the server.

NOTE
l l l l l
Log in to the XSCF of the M4000/M5000 server by using the IP address of the network port 0 of the XSCF. Log in to the http://support.huawei.com to download the PuTTY to the PC. Log in to the XSCF of the M4000/M5000 through the PuTTY. For details, see M2000 Software Initialization Installation Guide (T5220&M4000&M5000, S10). If the IP address of the XSCF is not assigned, use the HyperTerminal to log in from the serial port of the XSCF. Use the serial port cable to connect the serial port of the XSCF and the COM port of the PC. One end of the cable uses the RJ-45 connector, which is inserted into the serial port of the XSCF. The other end uses the DB-9 connector, which is inserted into the COM port of the PC. The port properties of the HyperTerminal must be restored to the default values. This means that you must set the bit rate to 9600, data digit to 8, parity check to none, stop bit to 1, and data stream control to none.
2. 3.
Type the adminuser account and the password to enter the Platform shell. Huawei recommends that you use adminuser as the password of the adminuser account. Run the following command to close domain 0. Then, only the XSCF board is running. All other boards are powered off. XSCF> poweroff -d 0
Step 3 Power off two disk arrays. The procedures for powering off the two disk arrays are consistent. Option S2600 disk array S3200 disk array or 6140 disk array Description Perform Step 3.1. Perform Step 3.3.
1.
Check whether the I/O activities of the disk arrays are stopped.
NOTE
a. Wait for two minutes. If the LED indicators of all the drives and caches stop blinking, you can infer that the read and write operations of the disk array are stopped. b. Check the cache LED on the controller and determine whether any data on the cache needs to be written to the disk. c. Ensure that the LEDs of all the drive and caches stop blinking.
2. 3.
Remove the two plugs at the rear of the disk array from the socket. Check whether the I/O activities of the disk arrays are stopped. a. Wait for two minutes. If all the LEDs stop blinking, you can infer that all the data is written into the disk and that the cache does not hold data. See Figure 2-25 .
2-28
Issue 03 (2010-08-31)
Figure 2-25 Disk array (I)
1 b.
OFF
ON
Ensure that all the LEDs of all the disk drives at the front of the controller stop blinking. See Figure 2-26. Figure 2-26 Disk array (II)
4.
NOTE
Step 4 If required, set the power switches of the cabinet and the other devices in the cabinet to OFF. ----End
Issue 03 (2010-08-31)
2-29
3 Managing Cluster Resources of the M2000 (HA)
Managing Cluster Resources of the M2000 (HA)
About This Chapter

This chapter describes how to manage the cluster resources of the M2000 HA system. 3.1 Introduction to Cluster Resources of the M2000 (HA) This section describes the cluster resources of the M2000 HA system. The resources consist of working principles of the Sun Cluster, resource planning of the M2000 HA system, and automatic switching of active and standby nodes. 3.2 Switching Over Active and Standby Nodes This lists the conditions for switching over active and standby nodes and describes how to switch over the active and standby nodes. 3.3 Registering the resource of the Sybase After the Sybase is registered in the Sun Cluster, the Sun Cluster can monitor the operating status of the Sybase in real time. when the Sybase is registered, modify the file /opt/SUNWscsyb/bin/ sybase_stop_servers on both Node1 and Node2. When the Sybase is registered on the Sun Cluster, the file is required to be modified only on Node1. 3.4 Registering the resource of the M2000 After the M2000 server application is registered on the Cluster, the M2000 server application is managed by the Cluster as the resource. The operation is executed only on Node1. 3.5 Managing Cluster Resources This section describes how to manage the cluster resource of the M2000 HA system. The process for managing the cluster resource involves starting and stopping the Cluster monitoring resources, the M2000 system service, and the Sybase.
Issue 03 (2010-08-31)
3-1
3.1 Introduction to Cluster Resources of the M2000 (HA)

This section describes the cluster resources of the M2000 HA system. The resources consist of working principles of the Sun Cluster, resource planning of the M2000 HA system, and automatic switching of active and standby nodes. 3.1.1 Work Principle of the Sun Cluster This section describes the working principle of the Sun Cluster and defines the switch mechanism, resource group, and resource. For details, refer to the user manual of the Sun Cluster. 3.1.2 Resource Planning for the M2000 (HA) This section describes the resource planning for the M2000 HA system. The resources consist of the Cluster, resource group, and detailed resource planning. 3.1.3 Automatic Switchover Conditions of Active and Standby Nodes This section describes the resource monitoring mechanism, principle of switching active or standby nodes, and automatic switching conditions for the M2000 HA system.
3.1.1 Work Principle of the Sun Cluster

This section describes the working principle of the Sun Cluster and defines the switch mechanism, resource group, and resource. For details, refer to the user manual of the Sun Cluster.
Introduction to the Sun Cluster

The Sun Cluster promotes the Solaris operating environment to a cluster operating system. As a collection of loose coupling computing nodes, the cluster provides a single customer view for network services or applications such as database, web service, and file service. The cluster supports the applications with high availability and flexibility.
Switching Mechanism
The cluster can automatically relocate the applications from a faulty active node to a specified standby node, and thus the Sun Cluster features high availability. If the active node, that is, the node running services, is faulty, the Cluster restarts the services on the same node. If the restart fails, the service is switched to the other node automatically. There may be a temporary interruption during the switchover and you may need to reconnect the two nodes after the switchover. The physical server that provides the applications and data, however, is visible.
Resource
Resource is the instance of the resource type defined in the cluster range. The same resource type may contain many resources and each resource has a name and an attribute group. In this case, instances of the basic applications can run on the cluster.
Resource Group
A resource group is a group of resources that are associated with each other. These resources depend on each other.
3.1.2 Resource Planning for the M2000 (HA)

This section describes the resource planning for the M2000 HA system. The resources consist of the Cluster, resource group, and detailed resource planning. Table 3-1 lists the factory settings of the Sun Cluster in the M2000 HA system. Table 3-1 Factory settings of the Sun Cluster Item Cluster Resource group Resource Name osscluster oss_rg osssvr_rs ossdg_rs sybase_rs ossapp_rs Description The Cluster name is unique in the entire network. Refer to the resource group of the system. Refers to the name of the host resource. Refer to the resource name of the disk array. Refer to the resource name of the Sybase. Refer to the application resource name of the M2000 .
The relations among the resources ossapp_rs, sybase_rs, ossdg_rs and osssvr_rs are as follows:
l l
The ossapp_rs resource depends on the sybase_rs resource. The sybase_rs resource depends on the ossdg_rs resource and osssvr_rs resource.
3.1.3 Automatic Switchover Conditions of Active and Standby Nodes

This section describes the resource monitoring mechanism, principle of switching active or standby nodes, and automatic switching conditions for the M2000 HA system.
M2000 Resource Monitoring Mechanism and Switchover Principle

The monitoring function of the M2000 monitors the M2000 janitor processes through the monitoring mechanism, and thus ensures the system security. When the system is faulty, the system can detect the fault and restart the application services quickly. The monitoring script monitors the imapsysd and imapwatchdog of the M2000 . The two janitor processes monitor other M2000 service progresses. In addition, the two janitor processes are responsible for automatic restart when the system is faulty. The Cluster of the HA system runs the monitoring script at intervals. The interval is the attribute value of Thorough_probe_interval of the M2000 resource ossapp_rs. The interval is set to
60 by default. If the script output is correct, the monitoring continues. If the script output is incorrect, the system invokes the script stop_OMC.sh and stops the M2000 services. The monitoring pauses during the period of stopping the service. When the services are stopped, the system invokes the script start_OMC.sh to start the M2000 services and counts the time at that point. After the interval of Thorough_probe_interval, the system starts the next monitoring service. If the services imapsysd and imapwatchdog are restarted successfully, the Cluster regards the M2000 as normal and thus continues the monitoring. If the services fail to restart, the system tries to restart the services for the times as given by Retry_count of ossapp_rs. The default value is 2. After the retry completes, the system counts the time from the restart time point and begins the next monitoring after the interval Thorough_probe_interval. If the output of monitoring script is still incorrect, the system starts the switchover and switches the resource from the active node to the standby node.
M2000 Switching Conditions

The Cluster switches the Sybase, M2000 server application, and disk array resources to the other server in the following cases:
l l l l l l l
CPU faults Memory faults Disk access faults Main board faults Disconnection between the host Ethernet adapter and the LAN switch Operating system faults Database faults
3.2 Switching Over Active and Standby Nodes

This lists the conditions for switching over active and standby nodes and describes how to switch over the active and standby nodes. 3.2.1 Automatic Switchover Conditions of Active and Standby Nodes This section describes the resource monitoring mechanism, principle of switching active or standby nodes, and automatic switching conditions for the M2000 HA system. 3.2.2 Manually Switching Over Active and Standby Nodes (HA) This section describes how to switch over active and standby nodes.
3.2.1 Automatic Switchover Conditions of Active and Standby Nodes

This section describes the resource monitoring mechanism, principle of switching active or standby nodes, and automatic switching conditions for the M2000 HA system.
3-4
Issue 03 (2010-08-31)
M2000 Resource Monitoring Mechanism and Switchover Principle

The monitoring function of the M2000 monitors the M2000 janitor processes through the monitoring mechanism, and thus ensures the system security. When the system is faulty, the system can detect the fault and restart the application services quickly. The monitoring script monitors the imapsysd and imapwatchdog of the M2000 . The two janitor processes monitor other M2000 service progresses. In addition, the two janitor processes are responsible for automatic restart when the system is faulty. The Cluster of the HA system runs the monitoring script at intervals. The interval is the attribute value of Thorough_probe_interval of the M2000 resource ossapp_rs. The interval is set to 60 by default. If the script output is correct, the monitoring continues. If the script output is incorrect, the system invokes the script stop_OMC.sh and stops the M2000 services. The monitoring pauses during the period of stopping the service. When the services are stopped, the system invokes the script start_OMC.sh to start the M2000 services and counts the time at that point. After the interval of Thorough_probe_interval, the system starts the next monitoring service. If the services imapsysd and imapwatchdog are restarted successfully, the Cluster regards the M2000 as normal and thus continues the monitoring. If the services fail to restart, the system tries to restart the services for the times as given by Retry_count of ossapp_rs. The default value is 2. After the retry completes, the system counts the time from the restart time point and begins the next monitoring after the interval Thorough_probe_interval. If the output of monitoring script is still incorrect, the system starts the switchover and switches the resource from the active node to the standby node.
M2000 Switching Conditions

The Cluster switches the Sybase, M2000 server application, and disk array resources to the other server in the following cases:
l l l l l l l
CPU faults Memory faults Disk access faults Main board faults Disconnection between the host Ethernet adapter and the LAN switch Operating system faults Database faults
3.2.2 Manually Switching Over Active and Standby Nodes (HA)

This section describes how to switch over active and standby nodes.
Context
Take the switchover from osssvr-1 to osssvr-2 as an example to describe the procedures for manual switchover.
Procedure
Step 1 Run the scstat command to check whether the system status is normal.
The online state means that the resource group is activated on the server. # scstat
------------------------------------------------------------------- Cluster Nodes -Node name --------osssvr-1 osssvr-2 Status -----Online Online
Cluster node: Cluster node:
------------------------------------------------------------------- Cluster Transport Paths -Endpoint -------osssvr-1:ce3 osssvr-1:ce1 Endpoint -------osssvr-2:ce3 osssvr-2:ce1 Status -----Path online Path online
Transport path: Transport path:
------------------------------------------------------------------- Quorum Summary -Quorum votes possible: Quorum votes needed: Quorum votes present: -- Quorum Votes by Node -Node Name --------osssvr-1 osssvr-2 Present Possible Status ------- -------- -----1 1 Online 1 1 Online 3 2 3
Node votes: Node votes:
-- Quorum Votes by Device -Device Name ----------/dev/did/rdsk/d4s2 Present Possible Status ------- -------- -----1 1 Online
Device votes:
------------------------------------------------------------------- Device Group Servers -Device Group -----------ossdg Primary ------osssvr-1 Secondary --------osssvr-2
Device group servers: -- Device Group Status --
Device group status:
Device Group -----------ossdg
Status -----Online
-- Multi-owner Device Groups -Device Group -----------Online Status -------------
------------------------------------------------------------------- Resource Groups and Resources --
3-6
Issue 03 (2010-08-31)
Group Name ---------Resources: oss_rg -- Resource Groups -Group Name ---------Group: oss_rg Group: oss_rg -- Resources -Resource Name ------------Resource: osssvr_rs - LogicalHostname online. Resource: osssvr_rs - LogicalHostname offline. Resource: ossdg_rs Resource: ossdg_rs Resource: sybase_rs Resource: sybase_rs - Adaptive_server: STOPPED Resource: ossapp_rs Resource: ossapp_rs
Resources --------osssvr_rs ossdg_rs sybase_rs ossapp_rs
Node Name --------osssvr-1 osssvr-2
State ----Online Offline
Node Name --------osssvr-1 osssvr-2 osssvr-1 osssvr-2 osssvr-1 osssvr-2 backup_server: STOPPED osssvr-1 osssvr-2
State ----Online Offline Online Offline Online Offline Online Offline
Status Message -------------Online Offline Online Offline Online Offline Online Offline
Step 2 Log in as user root to perform the switchover on the active or standby node. # scswitch -z -g oss_rg -h host name of Node2 Step 3 Check whether the switchover is successful. # scstat ----End
3.3 Registering the resource of the Sybase

After the Sybase is registered in the Sun Cluster, the Sun Cluster can monitor the operating status of the Sybase in real time. when the Sybase is registered, modify the file /opt/SUNWscsyb/bin/ sybase_stop_servers on both Node1 and Node2. When the Sybase is registered on the Sun Cluster, the file is required to be modified only on Node1. 3.3.1 Installing the Sybase Agent (HA) This section describes how to install the Sybase Agent on both node 1 and node 2. 3.3.2 Modifying the File sybase_stop_servers in the Folder /opt/SUNWscsyb/bin This task is performed to add user information about sa in the file /opt/SUNWscsyb/bin/ sybase_stop_servers. The task ensures that the Cluster passes verification when the Cluster starts the Sybase. You need to perform this operation on both Node1 and Node2. 3.3.3 Modifying the File sybase_start in the Folder /opt/SUNWscsyb/bin This section describes how to modify the startup waiting time of the Sybase in the /opt/ SUNWscsyb/bin/sybase_start file. This ensures that the Sybase database has enough time for startup and guarantees the correctness of sequent operations. Perform this operation on Node1 and Node2.
3.3.4 Registering the Sybase to the Sun Cluster This section describes how to register the Sybase system type and resource on the Sun Cluster through the regcluster.sh scripts after the M2000 server software is installed. When the active node has faults, the Sybase resource is automatically switched over to the standby node. Perform the task only on the active node. 3.3.5 Checking the Register of the Sybase Resource This section describes how to check whether the Sybase resource has been successfully registered on the Sun Cluster. Perform this task only on Node1. 3.3.6 Activating sybase_rs After the Sybase is registered and activated in the Cluster, the Cluster can monitor and manage the Sybase. This operation is performed only on Node1.
3.3.1 Installing the Sybase Agent (HA)

This section describes how to install the Sybase Agent on both node 1 and node 2.
Prerequisite
l l
Log in to node 1 and node 2 as user root through SSH mode. The M2000 server software has been correctly installed on Node1 and Node2.
Procedure
Step 1 Type the path of the Sybase Agent installation package.
l
To install the Sybase Agent installation package on node 1, run the following command: # cd /opt/OMC/etc/dual To install the Sybase Agent installation package on node 2, transfer the registration package /opt/OMC/etc/dual/SUNWscsyb.tar.gz in bin mode from node 1 to the path / tmp on node 2 through the FTP. Run the command ftp IP address of node 1 on node 2 and log in to node 1 as user root. Run the following commands: ftp> lcd /tmp ftp> cd /opt/OMC/etc/dual ftp> bin ftp> get SUNWscsyb.tar.gz ftp> bye After the files are transferred, run the following command to navigate to the installation directory of node 2: # cd /tmp
Step 2 Extract the package SUNWscsyb.tar.gz on node 1 and node 2. # gunzip SUNWscsyb.tar.gz # tar xvf SUNWscsyb.tar # pkgadd -d . Step 3 At the following prompt, press Enter.
The following packages are available: 1 SUNWscsyb Sun Cluster HA Sybase data service (sparc) 3.1.0,REV=2005.07.18.10.43 Select package(s) you wish to process (or 'all' to process all packages). (default: all) [?,??,q]:
Step 4 At the following prompt, press Enter:

Do you want to continue with the installation of <SUNWscsyb> [y,n,?]
The system prompts the following information after the installation of Sybase Agent.
Installation of <SUNWscsyb> was successful.
----End
3.3.2 Modifying the File sybase_stop_servers in the Folder /opt/ SUNWscsyb/bin

This task is performed to add user information about sa in the file /opt/SUNWscsyb/bin/ sybase_stop_servers. The task ensures that the Cluster passes verification when the Cluster starts the Sybase. You need to perform this operation on both Node1 and Node2.
Prerequisite
Log in to Node1 and Node2 as root through SSH mode.
Procedure
Step 1 Open /opt/SUNWscsyb/bin/sybase_stop_servers and run the following commands: # cd /opt/SUNWscsyb/bin # TERM=vt100; export TERM # vi sybase_stop_servers Step 2 Find the following contents in two different places in the file.
${SYBASE}/${SYBASE_OCS}/bin/isql -Usa -S${ADAPTIVE_SERVER_NAME}<<SVR_EOF
Step 3 Add the password of the sa user into the contents mentioned previously in the two different places. The modified contents is shown as follows:
${SYBASE}/${SYBASE_OCS}/bin/isql -Usa
NOTE
-S${ADAPTIVE_SERVER_NAME} -Pemsems<<SVR_EOF
The file sybase_stop_servers is read-only. To modify it, run wq! to write this file effectively, and then exit.
Step 4 Modify the file right of sybase_stop_servers. # chmod 500 sybase_stop_servers # chown dbuser:staff sybase_stop_servers ----End
3.3.3 Modifying the File sybase_start in the Folder /opt/ SUNWscsyb/bin

This section describes how to modify the startup waiting time of the Sybase in the /opt/ SUNWscsyb/bin/sybase_start file. This ensures that the Sybase database has enough time for startup and guarantees the correctness of sequent operations. Perform this operation on Node1 and Node2.
Prerequisite
Log in to Node1 and Node2 as user root through SSH mode.
Procedure
Step 1 Open the /opt/SUNWscsyb/bin/sybase_start file. # cd /opt/SUNWscsyb/bin # TERM=vt100; export TERM # vi sybase_start Step 2 Search the following line in the file and change 30 in this line to 120.
let ase_sleep_time=30
Step 3 Run the : wq! to forcibly exit. ----End
3.3.4 Registering the Sybase to the Sun Cluster

This section describes how to register the Sybase system type and resource on the Sun Cluster through the regcluster.sh scripts after the M2000 server software is installed. When the active node has faults, the Sybase resource is automatically switched over to the standby node. Perform the task only on the active node.
Prerequisite
l l l
Log in to the active node as user root through SSH mode. The M2000 server software has been correctly installed on Node1 and Node2. The Sybase service has been started.
Procedure
Step 1 Run the following commands to add the operation right to reg_syb.sh. # cd /opt/OMC/etc/dual # chmod 544 reg_syb.sh Step 2 Run the registration script reg_syb.sh. # . /opt/OMC/svc_profile.sh # ./reg_syb.sh SYB sa password of user sa
Step 3 When the system displays the following prompt, type the name of the resource according to 3.1.2 Resource Planning for the M2000 (HA). Please input Resource Group name [default:oss_rg]: Please input Disk Group Resource name [default:ossdg_rs]: Please input Sybase Resource name [default:sybase_rs]:
NOTE
In case a failure occurs, you can directly run the following command and enter information as prompted: # ./reg_syb.sh
Step 4 When the system displays the following prompt, enter y to continue.
Are you sure to continue? [y/n]:
----End
3.3.5 Checking the Register of the Sybase Resource

This section describes how to check whether the Sybase resource has been successfully registered on the Sun Cluster. Perform this task only on Node1.
Prerequisite
Log in to Node1 as user root through SSH mode.
Procedure
Step 1 Run the following command to check the status of the resource. # scstat -g
-- Resource Groups and Resources -Group Name ---------Resources: oss_rg -- Resource Groups -Group Name ---------Group: oss_rg Group: oss_rg -- Resources -Resource Name ------------Resource: osssvr_rs online. Resource: osssvr_rs Resource: ossdg_rs Resource: ossdg_rs Resource: sybase_rs Resource: sybase_rs Node Name --------osssvr-1 osssvr-2 osssvr-1 osssvr-2 osssvr-1 osssvr-2 State Status Message -----------------Online Online - LogicalHostname Offline Online Offline Offline Offline Offline Online Offline Offline Offline Node Name --------osssvr-1 osssvr-2 State ----Online Offline Resources --------osssvr_rs ossdg_rs sybase_rs
Issue 03 (2010-08-31)
3-11
If the system output contains sybase_rs, you can infer that the registration is successful. ----End
3.3.6 Activating sybase_rs

After the Sybase is registered and activated in the Cluster, the Cluster can monitor and manage the Sybase. This operation is performed only on Node1.
Prerequisite
l l
Log in to Node1 as root through SSH mode. Stop the Sybase service.
Procedure
Step 1 Run the following command to start the monitoring of the Sybase by the Sun Cluster. # scswitch -e -j sybase_rs The Cluster starts the Sybase. Step 2 Run the following command. The Sybase starts. # scstat -g
-- Resource Groups and Resources -Group Name ---------Resources: oss_rg -- Resource Groups -Group Name ---------Group: oss_rg Group: oss_rg -- Resources -Resource Name ------------Resource: osssvr_rs online. Resource: osssvr_rs Resource: ossdg_rs Resource: ossdg_rs Resource: sybase_rs Resource: sybase_rs Node Name --------osssvr-1 osssvr-2 osssvr-1 osssvr-2 osssvr-1 osssvr-2 State Status Message -----------------Online Online - LogicalHostname Offline Online Offline Online Offline Offline Online Offline Online Offline Node Name --------osssvr-1 osssvr-2 State ----Online Offline Resources --------osssvr_rs ossdg_rs sybase_rs
In this case, the Cluster ensures that the Sybase starts, and that the Sybase can be switched to the entire M2000 resource group. In the output, if the State of sybase_rs is Online on Node1(osssvr-1), infer that Sybase is running. If you do not want the Cluster to monitor the Sybase, run the scswitch -n -j sybase_rs command to stop the monitoring. The Sybase service is also stopped. # scswitch -n -j sybase_rs
CAUTION
In Cluster-managed HA mode, sybase_rs is monitored by the Cluster. Do not stop the Sybase server using isql. ----End
3.4 Registering the resource of the M2000

After the M2000 server application is registered on the Cluster, the M2000 server application is managed by the Cluster as the resource. The operation is executed only on Node1. 3.4.1 Installing the M2000 Registration Package This section describes how to install the M2000 registration package on node 1 and node 2. 3.4.2 Registering the M2000 Server Application to the Sun Cluster(Netra240&V890&E4900) This section describes how to register the server software on the Sun Cluster after the M2000 server software is installed. When the active node has faults, the M2000 resource is automatically switched over to the standby node. Perform the operation only on Node1. 3.4.3 Registering the M2000 Server Application to the Sun Cluster (T5220&M4000&M5000) This section describes how to register the server software on the Sun Cluster after the M2000 server software is installed. When the active node has faults, the M2000 resource is automatically switched over to the standby node. Perform the operation only on Node1. 3.4.4 Checking the Register of the M2000 Server Application This section describes how to check that the M2000 server software has been successfully registered on the Sun Cluster. Perform this task only on Node1. 3.4.5 Activating M2000 Resources This section describes how to activate the M2000 resources. After registering these resources on the Cluster, activate them so that the Cluster can monitor and manage them. You need to perform this operation on only Node 1.
3.4.1 Installing the M2000 Registration Package

This section describes how to install the M2000 registration package on node 1 and node 2.
Prerequisite
l l
Log in to node 1 and node 2 as user root through SSH mode. The M2000 server software has been correctly installed on Node1 and Node2.
Procedure
Step 1 Type the path of the M2000 registration package.
l
To install the M2000 registration package on node 1, run the following command: # cd /opt/OMC/etc/dual # cp M2kPkg.tar /tmp # cd /tmp
Issue 03 (2010-08-31)
3-13

l
To install the M2000 registration package on node 2, transfer the registration package /opt/ OMC/etc/dual/M2kPkg.tar in bin mode from node 1 to the path /tmp on node 2 through the FTP. Run the command ftp IP address of node 1 on node 2 and log in to node 1 as user root. Run the following commands: ftp> lcd /tmp ftp> cd /opt/OMC/etc/dual ftp> bin ftp> get M2kPkg.tar ftp> bye After the files are transferred, run the following command to go to the installation directory of node 2. # cd /tmp
Step 2 Extract the package M2kPkg.tar on node 1 and node 2. # tar xvf M2kPkg.tar # cd ./M2kPkg/HWM2000/pkg # pkgadd -d . At the following prompt: Select package(s) you wish to process (or 'all' to process all packages). (default: all) [?,??,q]: during the extraction, type all, and then press Enter to continue. At the following prompt: Do you want to continue with the installation of <HWM2000> [y,n,?] during the extraction, type y, and then press Enter to continue. When the system prompts # , you can infer that the extraction is completed ----End
3.4.2 Registering the M2000 Server Application to the Sun Cluster (Netra240&V890&E4900)
This section describes how to register the server software on the Sun Cluster after the M2000 server software is installed. When the active node has faults, the M2000 resource is automatically switched over to the standby node. Perform the operation only on Node1.
Prerequisite
l l
Log in to Node1 as user root through SSH mode. The M2000 registration package has been installed.
Procedure
Step 1 Run the following command to register the M2000 server software. # scrgadm -a -t HW.M2000 # scrgadm -a -j ossapp_rs -g oss_rg -t HW.M2000 -y Scalable=false -y Resource_dependencies=sybase_rs
If no information or the following information is displayed, you can infer that the registration is successful.
osssvr-1 - Current setting of Retry_interval = 300, might prevent failover on repeated probe failures. It is recommended that Retry_interval be greater than or equal to [(Thorough_probe_interval + Probe_timeout) * 2 * Retry_count]. Current values are (Thorough_probe_interval = 60,Retry_count = 2,Probe_timeout = 30). osssvr-2 - Current setting of Retry_interval = 300, might prevent failover on repeated probe failures. It is recommended that Retry_interval be greater than or equal to [(Thorough_probe_interval + Probe_timeout) * 2 * Retry_count]. Current values are (Thorough_probe_interval = 60,Retry_count = 2,Probe_timeout = 30).
----End
3.4.3 Registering the M2000 Server Application to the Sun Cluster (T5220&M4000&M5000)
This section describes how to register the server software on the Sun Cluster after the M2000 server software is installed. When the active node has faults, the M2000 resource is automatically switched over to the standby node. Perform the operation only on Node1.
Prerequisite
l l
You have logged in to Node1 as user root through SSH mode. The M2000 registration package has been installed.
Procedure
Step 1 Run the following command to register the M2000 server software. # scrgadm -a -t HW.M2000 # scrgadm -a -j ossapp_rs -g oss_rg -t HW.M2000 -y Scalable=false -y Resource_dependencies_offline_restart=sybase_rs If no information or the following information is displayed, then the registration is successful.
osssvr-1 - Current setting of Retry_interval = 300, might prevent failover on repeated probe failures. It is recommended that Retry_interval be greater than or equal to [(Thorough_probe_interval + Probe_timeout) * 2 * Retry_count]. Current values are (Thorough_probe_interval = 60,Retry_count = 2,Probe_timeout = 30). osssvr-2 - Current setting of Retry_interval = 300, might prevent failover on repeated probe failures. It is recommended that Retry_interval be greater than or equal to [(Thorough_probe_interval + Probe_timeout) * 2 * Retry_count]. Current values are (Thorough_probe_interval = 60,Retry_count = 2,Probe_timeout = 30).
----End
3.4.4 Checking the Register of the M2000 Server Application

This section describes how to check that the M2000 server software has been successfully registered on the Sun Cluster. Perform this task only on Node1.
Prerequisite
Log in to Node1 as user root through SSH mode.
Procedure
Step 1 Run the following command to check the status of the resource. # scstat -g
-- Resource Groups and Resources -Group Name ---------Resources: oss_rg -- Resource Groups -Group Name ---------Group: oss_rg Group: oss_rg -- Resources -Resource Name ------------Resource: osssvr_rs online. Resource: osssvr_rs Resource: ossdg_rs Resource: ossdg_rs Resource: sybase_rs Resource: sybase_rs Resource: ossapp_rs Resource: ossapp_rs Node Name --------osssvr-1 osssvr-2 osssvr-1 osssvr-2 osssvr-1 osssvr-2 osssvr-1 osssvr-2 State Status Message -----------------Online Online - LogicalHostname Offline Online Offline Online Offline Offline Offline Offline Online Offline Online Offline Offline Offline Node Name --------osssvr-1 osssvr-2 State ----Online Offline Resources --------osssvr_rs ossdg_rs sybase_rs ossapp_rs
If the system output contains ossapp_rs, you can infer that the registration is successful. ----End
3.4.5 Activating M2000 Resources

This section describes how to activate the M2000 resources. After registering these resources on the Cluster, activate them so that the Cluster can monitor and manage them. You need to perform this operation on only Node 1.
Prerequisite
l l
Log in to Node1 as user root through SSH mode. The sybase_rs resource has been activated.
Procedure
Step 1 Run the following commands to check all the M2000 services. # cd /opt/OMC # . ./svc_profile.sh # svc_ps If some services are running, run the following commands to stop all the M2000 services.
# stop_svc Step 2 Run the following commands to start the monitoring of the M2000 services by the Cluster. # scswitch -e -j ossapp_rs The Cluster starts the M2000 services. Step 3 Check whether the M2000 services are started. 1. Run the following command to check whether the M2000 services are started. # scstat -g
-- Resource Groups and Resources -Group Name ---------Resources: oss_rg -- Resource Groups -Group Name ---------Group: oss_rg Group: oss_rg -- Resources -Resource Name ------------Resource: osssvr_rs LogicalHostname online. Resource: osssvr_rs Resource: ossdg_rs Resource: ossdg_rs Resource: sybase_rs Resource: sybase_rs Resource: ossapp_rs Resource: ossapp_rs Node Name --------osssvr-1 osssvr-2 osssvr-1 osssvr-2 osssvr-1 osssvr-2 osssvr-1 osssvr-2 State ----Online Offline Online Offline Online Offline Online Offline Status Message -------------Online Offline Online Offline Online Offline Online Offline Node Name --------osssvr-1 osssvr-2 State ----Online Offline Resources --------osssvr_rs ossdg_rs sybase_rs ossapp_rs
The Cluster monitors the operating status of the M2000 in real time. In the output information, if the State of ossapp_rs on Node 1 is Online, you can infer that the M2000 services are started. During the startup of the M2000 services, you can run the following command on the Node 1 to view the startup logs of the M2000 services. # tail -f /opt/OMC/startsvc.log When the output information is similar to the following message, you can infer that the M2000 services are started.
============================ Finished Starting System. Starting resource monitor on osssvr-2 Starting resource monitor on osssvr-2 OK Fri Aug 1 08:41:47 GMT 2008
If you do not need the Cluster to monitor the M2000 server, run the following command to stop the monitoring. The M2000 services, however, are also stopped.
# scswitch -n -j ossapp_rs
CAUTION
l
In Cluster-managed HA mode, do not run the stop_svc command to stop the M2000 server except that the ossapp_rs resources are not monitored by the Cluster. After registering the Sybase software and the M2000 resources on the Cluster, you must run the following commands to stop the M2000 and Sybase monitoring before stopping the server. # scswitch -n -j ossapp_rs # scswitch -n -j sybase_rs # scshutdown -g0 -y
2.
Run the following command to check the operating status of the M2000 services. Ensure that all the M2000 services are started. # svc_adm -cmd status In the output information, if the value of Not Running : is 0, you can infer that all the M2000 services are started. Otherwise, perform Step 1 through Step 3 to activate the M2000 resources again.
----End
3.5 Managing Cluster Resources

This section describes how to manage the cluster resource of the M2000 HA system. The process for managing the cluster resource involves starting and stopping the Cluster monitoring resources, the M2000 system service, and the Sybase. 3.5.1 Viewing Configured Resources This section describes how to view the configured resources. 3.5.2 Starting Cluster Monitoring on Resources This section describes how to start Cluster monitoring on resources. 3.5.3 Stopping Cluster Monitoring on Resources This section describes how to stop Cluster monitoring on resources. 3.5.4 Starting the M2000 Services (HA) This section describes how to start the M2000 system services. After you run the command, all the M2000 services are started. The system ignores the service that is already started and starts only the inactive services. 3.5.5 Stopping M2000 Services (HA) This section describes how to run the command scswitch to stop all the M2000 services. After all the M2000 services are stopped, NE performance data and alarm data cannot be processed. After the M2000 services are resumed, the M2000 updates data with the NEs and processes the updated data. 3.5.6 Starting the Sybase (HA) This section describes how to start the Sybase for the HA system.
3.5.7 Stopping the Sybase (HA) This section describes how to stop the Sybase in the HA system.
3.5.1 Viewing Configured Resources

This section describes how to view the configured resources.
Prerequisite
Log in to the server as user root through SSH mode.
Procedure
Step 1 Run the scstat -g command to view the resources in the oss_rg resource group. # scstat -g The oss_rg resource group contains osssvr_rs, ossdg_rs, sybase_rs, and ossapp_rs. ----End
3.5.2 Starting Cluster Monitoring on Resources

This section describes how to start Cluster monitoring on resources.
Prerequisite
Procedure
Step 1 If a resource is not monitored by the Cluster, run the following command to start the Cluster monitoring on the resource. # scswitch -e -j resource name Run the following command to enable the Cluster monitoring on the Sybase: # scswitch -e -j sybase_rs Run the following command to enable the Cluster monitoring on the M2000: # scswitch -e -j ossapp_rs
NOTE
After running the scswitch -e -j command, you can enable the monitoring of a resource and start the resource. For example, after you run the scswitch -e -j ossapp_rs command to enable the monitoring of M2000 resources, the cluster also starts the M2000 system service.
----End
3.5.3 Stopping Cluster Monitoring on Resources

This section describes how to stop Cluster monitoring on resources.
Prerequisite
Context
The Cluster monitors all the resources in the resource group. If a resource is faulty, the Cluster attempts to restart the resource. The Cluster switches oss_rg to the standby node if the number of restart attempts reaches the preset value.
Procedure
Step 1 Stop Cluster monitoring on the resources. # scswitch -n -j resource name Run the following command to stop Cluster monitoring on the Sybase: # scswitch -n -j sybase_rs Run the following command to stop Cluster monitoring on the M2000: # scswitch -n -j ossapp_rs
NOTE
l l
The scswitch -n -j command helps you stop a resource. For example, after you run the scswitch -n j sybase_rs command, the Sybase is stopped. The stopped resource cannot restart automatically after the server restarts. In this situation, you must start the resource manually.
----End
3.5.4 Starting the M2000 Services (HA)

This section describes how to start the M2000 system services. After you run the command, all the M2000 services are started. The system ignores the service that is already started and starts only the inactive services.
Prerequisite
l l
Log in to the active node as user root through SSH mode. The Sybase services are running properly. For details about how to start the Sybase services, see 16.2.2 How to Start the Sybase (HA, Sun).
Context
NOTE
The time required for starting M2000 system services is related to the actual environment. Generally, it takes about 20 minutes.
Procedure
l 1. Run the following command: # scswitch -e -j ossapp_rs
3-20
Issue 03 (2010-08-31)

NOTE
l l
In the HA system, starting services requires some time. Wait about 10 minutes until all services are started and then you can perform operations on the HA system. When you start M2000 system services, the status of each service is displayed. If the status of a service is failed, you can infer that the service fails to be started. In this case, you can locate the fault by viewing the iMAP.troubleshooting.trace log on the active node. # more /export/home/omc/var/logs/iMAP.troubleshooting.trace
----End
3.5.5 Stopping M2000 Services (HA)

This section describes how to run the command scswitch to stop all the M2000 services. After all the M2000 services are stopped, NE performance data and alarm data cannot be processed. After the M2000 services are resumed, the M2000 updates data with the NEs and processes the updated data.
Prerequisite
Log in to the M2000 as user root through SSH mode.
Context
NOTE
The time required for stopping M2000 system services is related to the actual environment. Generally, it takes about 20 minutes.
Procedure
l 1. Run the command: # scswitch -n -j ossapp_rs
NOTE
The HA system takes some time to stop the services. Wait for ten minutes after you run the command. Run the command svc_ps to monitor the service stopping progress.
----End
3.5.6 Starting the Sybase (HA)

This section describes how to start the Sybase for the HA system.
Prerequisite
l l
Log in to the server as user root through SSH mode. The osssvr_rs resource and ossdg_rs resource are already activated on the active node.
Context
l
Run the following command to check the status of each resource on the active and standby nodes of the HA system: # scstat
Issue 03 (2010-08-31)
3-21
The online status means that the resource group is activated on the server.
l
On the active node, run the following command to activate the osssvr_rs resource: # scswitch -e -j osssvr_rs On the active node, run the following command to activate the ossdg_rs resource: # scswitch -e -j ossdg_rs
Procedure
Step 1 Run the following command to start the Sybase: # scswitch -e -j sybase_rs ----End
3.5.7 Stopping the Sybase (HA)

This section describes how to stop the Sybase in the HA system.
Prerequisite
l l
Log in to the server as user root through SSH mode. The M2000 service is already stopped. For details about how to stop the M2000 service, see 3.5.5 Stopping M2000 Services (HA).
Procedure
Step 1 Run the following command to stop the Sybase: # scswitch -n -j sybase_rs ----End
3-22
Issue 03 (2010-08-31)
4 Setting the M2000 Time (HA)
4
About This Chapter
Setting the M2000 Time (HA)
This chapter describes how to set the server time and the client time to ensure that the specified time meets the requirements and is synchronized with the Huawei mobile equipment. 4.1 Time Management for the Huawei Mobile Network This section describes the time synchronization solution of the Huawei mobile network. By using the time synchronization solution, you can synchronize time between the M2000 and other Huawei mobile network devices. In addition, the M2000 supports the setting of DST and the automatic change according to the preset DST rules. 4.2 Modifying the Date and Time on the M2000 Server (HA) This section describes how to modify the data and time on the M2000 server. The correct server time is important for collecting NE data, handling real-time tasks, and dumping the database information. 4.3 Changing the Time Zone of the M2000 Server Without Using DST (HA) This section describes how to change the time zone of the M2000 server in an HA system. The correct server time zone is closely associated with collecting NE data, handling timing tasks, and dumping database information. Therefore, you need to set the server time zone correctly to ensure the normal operation of the system. 4.4 Modifying the Date, Time, and Time Zone on the M2000 Client This section describes how to modify the date, time, and time zone on the M2000 client running the Windows operating system. You can modify the date, time, and time zone on the M2000 client by modifying the date, time, and time zone of the Windows. 4.5 Configuring the NTP Service of the M2000 (HA) This section describes how to set the M2000 server in an HA system as the NTP client and synchronize time with the upper-layer server and how to set the M2000 client as the NTP client and synchronize time with the M2000 server. 4.6 Setting DST for the M2000 (HA) This section describes how to set the time zone of the M2000 server to ensure that DST is supported in an HA system. If DST change occurs on an NE, ensure that the M2000 can handle the data reported by the NE and that no reported data is missing.
Issue 03 (2010-08-31)
4-1
4.1 Time Management for the Huawei Mobile Network

This section describes the time synchronization solution of the Huawei mobile network. By using the time synchronization solution, you can synchronize time between the M2000 and other Huawei mobile network devices. In addition, the M2000 supports the setting of DST and the automatic change according to the preset DST rules. 4.1.1 Introduction to Time Synchronization This section describes the purpose and definition of time synchronization, the elements of the time synchronization solution, and the impact on system performance and other OM features after the time synchronization solution is implemented. 4.1.2 Introduction to the NTP/SNTP This introduces the rationale of time synchronization and the layered architecture of the Network Time Protocol (NTP) and the Simple Network Time Protocol (SNTP). 4.1.3 Time Synchronization Modes of Huawei Mobile Network This section describes the modes of time synchronization and how to deploy the time synchronization network for the M2000 and NE devices in Huawei mobile network. 4.1.4 Introduction to the DST This section describes the daylight saving time (DST) and the DST impact on the M2000 system.
4.1.1 Introduction to Time Synchronization

This section describes the purpose and definition of time synchronization, the elements of the time synchronization solution, and the impact on system performance and other OM features after the time synchronization solution is implemented.
Purpose of Time Synchronization

Time synchronization enables you to synchronize time between the M2000 and other NEs. The networking mode of a mobile network is complex if the mobile network has multiple NEs. The uniform OM mode of NEs in a mobile network requires the time synchronization between NEs. This ensures that the M2000 correctly manages the alarms and performance data reported by the NEs. Inaccurate time may lead to the following scenarios:
l
If the alarm time is inaccurate, the sequence of generated alarms, the interval between alarm generation and alarm reporting, and the associations between alarms may be misjudged. When the M2000 collects the statistics of performance data, the statistics are incorrect owing to inaccurate time.
Therefore, time synchronization enables the system to automatically adjust the OM time of NEs.
Definition of Time Synchronization

Time synchronization is the synchronization of absolute time. The start time of a signal should be consistent with the universal coordinated time (UTC). Time synchronization aims to adjust the time of devices according to the received time.
Elements of the Time Synchronization Solution

At least two elements are involved in the time synchronization solution, namely, the method of time synchronization and the choice of time reference sources.
l
In the architecture of the current time synchronization networking, the common method is to implement time synchronization according to the Network Time Protocol (NTP) and the Simple Network Time Protocol (SNTP). Time reference sources aim to provide the standard reference time for the time synchronization network. This ensures the accuracy of the time reference in the entire network. A common time reference source is the GPS satellite.
Impact on System Performance

If time synchronization is implemented in client/server mode described in the NTP protocol, the message frame between the NTP client and the NTP server is 128 bytes. Therefore, time synchronization does not affect the performance of network transmission. If a great number of NTP clients request to connect to the NTP server at the same time, these connections consume mass resources, such as the CPU and the memory of the NTP server. As a result, the performance of the NTP server is affected. Therefore, if you use the NTP protocol to construct a time synchronization network, the number of NTP nodes under an NTP server should not exceed 300. If the number exceeds 300, the performance of the NTP server may be affected. The interval for the time synchronization request of an NTP client should be 30 minutes or longer. In addition, you need to reduce the probability of concurrent requests.
Impact on OM
The time synchronization feature is vital for the OM of the mobile network. It has the following impacts on the other features:
l
Ensures the accuracy and consistency of the time on the M2000 and NEs in a mobile network. Time synchronization plays a key role in timely fault reporting, information accuracy, and fault correlation analysis in fault management. If the NE time is inaccurate or inconsistent with the M2000 time, a mistake may be made during the fault identification and handling. Has a significant impact on the accuracy of log record, query, display, audit, and analysis. If the time is inaccurate or the time of NEs in the entire network is not the same, the log record is incorrect and the log audit is also affected. Has a significant impact on recording, collecting, and analyzing performance data in performance management. If the time is inaccurate or the time of NEs in the entire network is not the same, the time of NE performance data records and the dot time may be inaccurate, and thus may result in invalid performance data. Has a significant impact on services such as call tracing and problem locating. If the time is inaccurate or the time of NEs in the entire network is not the same, the call tracing service may fail.
4.1.2 Introduction to the NTP/SNTP

This introduces the rationale of time synchronization and the layered architecture of the Network Time Protocol (NTP) and the Simple Network Time Protocol (SNTP).
Rationale of NTP Time Synchronization

NTP is used to synchronize the time between the distributed time server and the client. It defines the structure, algorithm, entity, and protocols in the process of time synchronization. Based on the IP and UDP stack protocol in the TCP/IP protocols, NTP can also be used by other protocol groups. Theoretically, the error is less than one nanosecond. Figure 4-1 shows the rationale of NTP time synchronization. Figure 4-1 NTP rationale
Device A and device B communicate through the network. Both devices have their own system time. To implement the automatic synchronization of system clocks, ensure that:
l
Before you synchronize the system time of device A and device B, the time on device A is set to 10:00:00 and the time on device B is set to 11:00:00. Device B is configured as the NTP server. That is, you need synchronize the time on device A with that on device B. The unidirectional transmission of data package between device A and device B takes one second.
To synchronize the time between device A and device B, ensure that the following information is available:
l l
Offset, which is the time difference between device A and device B Delay, which is the loss during the time synchronization between device A and device B
If the previous information is available, device A can easily calculate the time to be adjusted to synchronize with device B. The NTP protocol stipulates the method for calculating the values of the offset and delay between device A and device B. The time synchronization process is as follows: 1. 2. Device A sends an NTP message to device B. The message records the stamp of the leaving time from device A, which is 10:00:00am (T1). When the NTP message reaches device B, device B adds its own time stamp, which is 11:00:01am (T2).
4-4
3. 4.
When the NTP message leaves device B, device B adds its own time stamp again, which is 11:00:02am (T3). When device A receives the response message, it adds a new time stamp, which is 10:00:03am (T4).
After that, device A can calculate the two parameters using the following method:
l l
Delay of a NTP message delivering circle: delay = (T4 - T1) - (T3 - T2). Offset between device A and device B: offset = [(T2 - T1) + (T3 - T4)]/2.
Then, device A can set the time according to this previous information so that device A is synchronized with device B.
Rationale of NTP Layered Architecture

From the origin and purpose of the time synchronization mechanism, you can infer that fewer clock sources enables more uniform time. If a network has a large scale and is very complex, it is time-consuming to connect each device to the same time server if the time of each device needs to be synchronized. In such a case, the layered architecture is applied to the NTP model. Theoretically, the time synchronization network can be classified into 16 levels from 0 to 15, or more than 16 levels on the basis of accuracy and importance. In practice, the number of levels does not exceed six. The device at level 0 is located at the special position of the subnetwork. It provides the reference clock for time synchronization. On the top of the subnet, the device at level 0 uses UTC time codes broadcast by the global positioning system (GPS). The devices in the subnet can play multiple roles. For example, a device on the second layer may be a client to the first layer and a server for the third layer. Figure 4-2 NTP layered architecture
As shown in Figure 4-2, the following servers are configured in the NTP layered architecture:
l
Top level NTP server: level 0 NTP server, which provides the synchronization service for lower level servers (Stratum-1).
Issue 03 (2010-08-31)

l
Medium level NTP server: level 1 and level 2 servers, which acquires time from the upper level server and provides the time for the lower level servers. NTP client: acquires time from upper level NTP server but does not provide time service.
A host can acquire time from multiple NTP servers. An NTP server can also provide time for multiple hosts. Hosts on the same level can exchange time. The NTP protocol supports a maximum of 15 clients.
NOTE
Port 123 is used by NTP during communication through the User Datagram Protocol (UDP). Ensure that all the IP links between the nodes are functional.
Comparison of SNTP and NTP

SNTP is a simplified policy for the NTP server and the NTP client. The difference between SNTP and NTP is that SNTP has disadvantage over the following aspects:
l l l
Handling errors Filtering of multiple servers Choosing among multiple clock sources, that is, acquiring the most accurate clock resource after using an algorithm to analyze multiple connected NTP servers.
4.1.3 Time Synchronization Modes of Huawei Mobile Network

This section describes the modes of time synchronization and how to deploy the time synchronization network for the M2000 and NE devices in Huawei mobile network.
Time Synchronization Modes of the M2000

The time synchronization of a mobile network is implemented through the NTP/SNTP protocols. The M2000 server uses Solaris 10 and supports the NTP features based on NTPV3 protocol versions. By setting the parameters in the file /etc/inet/ntp.conf on the Solaris operating system, you can set the M2000 server as an NTP client in the mobile network. Specify an IP address for the NTP server that the M2000 server gains access to, the M2000 server can obtain the time synchronization information from the specified NTP server. In addition, you can configure the M2000 administration console as an intermediate time server. The M2000 client runs on the Windows 2000 Professional or Windows XP operating system. You need to configure an operating system to support the SNTP client and specify the IP address of the NTP server. Then, the M2000 client can obtain the time synchronization information from the specified NTP server.
NOTE
The upper-level time servers of the M2000 server and the administration console require to use the NTP protocol. The server running the Windows operating system uses the SNTP protocol, and thus it cannot function as the upper-level time server of the M2000 server and the administration console.
Time Synchronization Modes of NEs

l
For an NE with the BAM, the NE time synchronization follows the master/slave networking mode. That is, the host time synchronizes with the BAM and the BAM synchronizes with the NTP server.
4-6

l
For an NE without the BAM, the OM board needs to support the NTP protocol. Therefore, the NE can synchronize with the NTP server.
This part takes device A as an example.

l
Rationale of time synchronization for device A
Figure 4-3 Schematic diagram of time synchronization for device A
The active BAM of device A serves as the NTP client to synchronize the time on each NE node and each module of device A, as shown in Figure 4-3. After the active BAM of device A obtains the reference time from the specified NTP server, the BAM delivers the time to each module of device A and all device B to realize time synchronization.
l
The BAM of device A synchronizes time with the upper-layer NTP server. Device A has two BAM servers, that is, the active and standby BAM servers. In the BAM program of device A, an NTP client process automatically starts after the BAM program and always runs on the active BAM server. By running MML commands, you can specify the upper-layer NTP server as the active BAM server of device A. Then, the NTP client process running on the active BAM automatically obtains the time synchronization information from the specified NTP server. A maximum of 16 NTP server addresses can be specified for the active BAM. The active BAM of device A can perform the synchronization from the preferred time source. If an NTP time source does not work properly, the active BAM can use a new NTP time source to ensure the continuity of the NTP service.
Issue 03 (2010-08-31)
4-7
When the BAM of device A experiences active and standby switching, the NTP client process is automatically switched to the new active BAM to ensure the continuity of the NTP service.
l
Time synchronization for each internal module of device A In addition to running the NTP client to synchronize with the external time sources, the active BAM of device A has an SNTP server module for time synchronization between the internal modules. For device A, each internal module has an independent process serving as the SNTP client. The active BAM of device A serves as the SNTP server of all the modules. By running the MML commands, you can configure the SNTP server attributes for the active BAM of device A.
Time synchronization for the standby BAM of device A If the active and standby BAMs are operational, only the active BAM has the SNTP server, and the SNTP client on the standby BAM is used only to periodically synchronize the time with the active BAM. That is, when the active and standby BAMs are operational, the time of the active BAM is regarded as the reference time. During the time synchronization of the active and standby BAMs, the SNTP client of the standby BAM requests for time synchronization, the SNTP server of the active BAM returns a response message. Then, the standby BAM adjusts the time of the applications and the system based on the response message. The time synchronization of the active and standby BAMs is performed every five minutes. Manual setting of the period is not required because the active and standby BAMs work as a single entity to provide services.
Time synchronization between device B and the BAM of device A The SNTP server of the active BAM provides both the time synchronization service and the time comparison service for the host. The SNTP server of the active BAM periodically broadcasts time synchronization messages to device B and receives the requests for time synchronization from device B. Device B runs an SNTP process and sends requests for time synchronization to the active BAM of device A.
Network of NTP Time Synchronization

The NTP time synchronization network determines the reference time for the network and uses the reference time to specify how device nodes communicate with each other. This part takes device A for example to describe how to choose the reference time for the NTP time synchronization network.
l
Using the NTP server specified by the carrier If the established time synchronization network provides the NTP server that can act as the reference time source, it is preferred to use the existing NTP server as the time reference source of the RAN network. In this case, the M2000 and the BAM server of device A need to directly communicate with the specified NTP server to obtain standard time signals, as shown in Figure 4-4.
4-8
Issue 03 (2010-08-31)
Figure 4-4 Directly connecting device A and the NTP server
The M2000 server and all the devices must directly communicate with the specified time synchronization server. The NTP server that can serve as the reference time may be deployed in other subnets. Therefore, the communication between the M2000 and device A may involve the policy of traversing the firewall. In such a case, you need to modify the configuration of the firewall.
l
Deploying the intermediate-layer NTP server According to the principle of layered NTP, when constructing an RAN network, you can deploy a dedicated intermediate-layer NTP server in the RAN-OM network to serve as the time reference for the internal RAN devices. The intermediate-layer NTP server obtains the reference time from the upper-layer server, synchronizes its own time, and serves as the NTP server of the RAN network. In such a case, the intermediate-layer NTP server can receive the request on time synchronization from the internal NE devices in the RAN, such as device A and the M2000, and provides standard time, as shown in Figure 4-5.
Issue 03 (2010-08-31)
4-9
Figure 4-5 Networking of device A and the intermediate-layer NTP server
Deploying the intermediate-layer NTP server can effectively simplify the structure of the time synchronization network. It can also prevent too many NEs from directly connecting the highest layer NTP server, thus reducing the risks to the highest layer NTP server. In addition, if a firewall exists between the highest layer NTP server and the RAN network, the workload on configuring the firewall is reduced. You can use the dedicated BITS SYNCLOCK V5 as the NTP intermediate-layer server of device A network. Complying with the NTP V3 protocols, this device can provide two channels of NTP service units and lock multiple upper-layer NTP servers to realize NTP priority. The intermediate-layer NTP server provides two channels of NTP service output that are mutually backed up.
4-10
Issue 03 (2010-08-31)

NOTE
The M2000 server uses the Solaris operating system where you can configure the M2000 server as the intermediate-layer NTP server. The time synchronization server for the RAN network plays a special role and requires an independent and stable operating environment. Therefore,Huawei recommends that the M2000 server should not serve as the intermediate-layer NTP server for the RAN network. When a system using the Netra 240, V890 or E4900 server, the Netra 240 server is integrated as an administration console by default. In this case, the Netra 240 acts as the intermediate-layer NTP server for the RAN network.
Obtaining reference time from the GPS If the upper-layer time synchronization server that can provide the reference time is not available, you should deploy the highest layer NTP server, that is, the NTP server providing the reference time in the RAN-OM network to ensure time synchronization. The highest layer NTP server obtains the reference time from the GPS or other satellite systems and synchronizes time on all the RAN NEs and the M2000. Figure 4-6 shows the networking of device A and the highest layer NTP server. Figure 4-6 Directly connecting device A to the highest layer NTP server
Issue 03 (2010-08-31)
4-11
You can use the dedicated BITS SYNCLOCK V5 as the highest layer NTP server of device A. Complying with the NTP V3 protocol, this device can provide two channels of the satellite access system and two channels of NTP service units. It also provides two channels of NTP service output that are mutually backed up.
NOTE
To improve the reliability of the NTP service, ensure that the following methods are applicable:
l
Choose two or more NTP servers that serve as the upper-layer NTP server to provide time reference. When deploying the upper-layer NTP server for NEs and the M2000, ensure that more than two channels of the NTP service are available. If the stratum 1 NTP server is deployed, it obtains reference time directly from the GPS satellite. In such a case, the stratum 1 NTP server should provide two channels of satellite interfaces.
4.1.4 Introduction to the DST

This section describes the daylight saving time (DST) and the DST impact on the M2000 system.
Introduction
The DST is one hour earlier than the standard time. For example, during the DST, 10:00 am in US east standard time is 11:00 am in US east DST.
Impact on the M2000 System

l
When the DST starts, generally one hour is automatically added to the local time of the operating system. This change does not affect the system clock of the M2000. The M2000 log management and trace management uses the local time. Therefore, one-hour records are missing in trace files. When the DST ends, generally one hour is automatically reduced from the local time of the operating system. This change does not affect the system clock. Thus, time storage and exchange are not affected. This change, however, affects the time display. During the operation of the M2000, some modules in the M2000 generate some files whose names are identified by time stamps. When the DST ends, files that are generated later overwrite the earlier ones.
NOTE
l l
The local time is the time displayed on the computer. It varies according to the time zone. The system clock indicates the GMT. The NTP synchronization uses the GMT, which does not affect the local time. The DST does not affect the NTP service.
4.2 Modifying the Date and Time on the M2000 Server (HA)
This section describes how to modify the data and time on the M2000 server. The correct server time is important for collecting NE data, handling real-time tasks, and dumping the database information.
Prerequisite
l
Log in to the two nodes as user root through SSH mode by using the corresponding physical IP addresses. The Sybase and the M2000 services are stopped.
4-12
Context
The Sun Cluster uses the NTP to synchronize the time among the Cluster nodes.
CAUTION
l
Modifying the server time results in a change in the Solaris lower layer time. This may further result in the reset or failure of the timer that relies on the Solaris operating system. Thus, to avoid the timer failure, you must first stop the M2000 and Sybase services before changing the server time. During the period when you change the server time, the performance data and alarm data of the managed NEs cannot be handled in time. After the Sybase and the M2000 services are restored, the M2000 enables the automatic synchronization function to recollect and handle the missing performance data and alarm data. When the M2000 serves as the clock source of the NTP service, the time on the NEs is synchronized automatically after the server is modified. Adjusting the cluster date involves using the commands date, rdate, or xntpdate interactively or using these commands in the cron script. The modified server time takes effect immediately. The changed time zone of the server takes effect only after you restart the server. If you need to modify both the time zone and the time, change the time zone first. When modifying the server time, ensure that the changed server time is within the validity period of the license. If the server time exceeds the license validity period, certain services cannot be enabled.
Procedure
Step 1 Check the system date and time on node 1 and node 2. # date If the system date and time are incorrect, perform the subsequent steps to correct the date and time. Step 2 Shut down the cluster on the active node. # /usr/cluster/bin/scshutdown -g0 -y Step 3 Log in to both servers through the SC, RSC, or XSCF, switches to the ok state. For details, see the M2000 HA System Software Initial Installation Guide (Sun, S10). Step 4 Run the following commands at the two nodes, start node 1 and node 2 in non-cluster mode. ok boot -x Step 5 Log in to node 1 and node 2 as user root. Step 6 On node 1, run the date command to set the system date and time. # date mmddHHMMYYYY.SS Set the system date and time to 2005-11-17 16:30:43. # date 111716302005.43
Mon Nov 17 16:30:43 CST 2005 You must set a correct date. Otherwise, the modification of the M2000 server date and time fails.
NOTE
If the GMT time is used, run the date -u mmddHHMMYYYY.SS command.
Step 7 Run the following command on node 1 and node 2 to start network time: # svcadm enable svc:/network/time:stream Step 8 On node 2, run the command rdate to synchronize the time with node 1. # rdate host name of node 1 Step 9 Verify the new time on both node 1 and node 2. # date Step 10 Restart the server on node 1 and node 2. # /usr/sbin/shutdown -i6 -g0 -y ----End
4.3 Changing the Time Zone of the M2000 Server Without Using DST (HA)
This section describes how to change the time zone of the M2000 server in an HA system. The correct server time zone is closely associated with collecting NE data, handling timing tasks, and dumping database information. Therefore, you need to set the server time zone correctly to ensure the normal operation of the system.
Prerequisite
Log in to both nodes as user root through SSH mode by using the corresponding physical IP addresses.
Context
l
On the Solaris operating system, two time formats are available for the time zone: GMT and time zone code. The GMT format stipulates only time offset rather than the DST rules. The time zone code format stipulates the time offset and the DST rules, depending on time zones. The GMT format can be used by the countries and regions that do not use DST. The time zone code format must be used by the countries and regions that use DST. Otherwise, the operating system does not support the automatic DST change. The change of the server time zone results in the change of time at the Solaris bottom layer. In this case, all the timers depending on the operating system are reset or become invalid. To avoid the function failure caused by invalid timers, you need to stop the M2000 and Sybase services before you change the server time zone. During this period, the performance data and alarm data of the managed NEs cannot be handled in time. After the M2000 and Sybase services are restored, the M2000 starts the automatic synchronization
4-14
function, and collects and handles the missing performance data and alarm data from the managed NEs.
l l
If you need to change both the time and the time zone, change the time zone first. If the M2000 HA system does not use DST, you need to change the time zone of the server by performing the following operations. Otherwise, you need to change the time zone of the server by referring to 4.6 Setting DST for the M2000 (HA). Coordinated Universal Time, which is referred to as Greenwich Mean Time (GMT), is taken as a reference. The time zone of the region to the east of the GMT region is represented by GMT+N. That is, the time of the region is N hours earlier than the GMT. The time zone of the region to the west of the GMT region is represented by GMT-N. That is, the time of the region is N hours later than the GMT. For example, GMT+08:00 is eight hours earlier than the GMT and GMT-08:00 is eight hours later than the GMT. When you modify the time zone configuration file /etc/TIMEZONE of the Solaris, GMT+N refers to the time zone that is N hours later than the GMT and GMT-N refers to the time zone that is N hours earlier than the GMT.
Procedure
Step 1 Run the following command on both node 1 and node 2 to check the time zone of the server: # echo $TZ If the time zone of the server is incorrect, perform the following steps to change it: Step 2 If the M2000 services are running, run the following command on the active node to stop them: # scswitch -n -j ossapp_rs Step 3 Run the following command on the active and standby nodes and check whether there is any command result: If no system output is displayed, you can infer that the M2000 daemon is terminated. # . /opt/OMC/svc_profile.sh # daem_ps Step 4 If the daemon process is still running, run the following command to forcibly stop it: # kill_daem Step 5 If the Sybase services are running, run the following command on the active node to stop the Sybase services: # scswitch -n -j sybase_rs Step 6 On node 1 and node 2, modify the /etc/TIMEZONE file and change the value of TZ to the name of the required time zone. # TERM=vt100; export TERM # vi /etc/TIMEZONE For example, set TZ to GMT+8.
Issue 03 (2010-08-31)
4-15

NOTE
l l
The time zone configurations of the active and standby nodes must be the same. In this case, GMT+N indicates that the local time is N hours later than the GMT. GMT-N indicates that the local time is N hours earlier than the GMT. Before the change, ensure that the binary time zone file corresponding to the GMT time zone exists in the /usr/share/lib/zoneinfo directory. Otherwise, the change fails. The /etc/TIMEZONE file is read-only. Save the file after modification.
Step 7 Run the following command on the active node to stop the cluster system: # /usr/cluster/bin/scshutdown -g0 -y Step 8 Log in to both servers through the SC, RSC, or XSCF, switches to the ok state. For details, see the M2000 HA System Software Initial Installation Guide (Sun, S10). Step 9 Run the following command to restart the server: ok boot
NOTE
Start node 1 first. Wait for three minutes, and then start node 2.
Step 10 Log in to node 1 and node 2 as user root through SSH mode. Step 11 If the Sybase services are stopped in Step 5, run the following command on node 1 or node 2 to start the Sybase services: # scswitch -e -j sybase_rs Step 12 If the M2000 services are stopped in Step 2, run the following command on node 1 or node 2 to start the M2000 services: # scswitch -e -j ossapp_rs Step 13 Run the following command on the standby node to check whether there is any output: # . /opt/OMC/svc_profile.sh # daem_ps
l l
If any output exists, you can infer that the daem process is started. If no output exists, you can infer that the daem process is not started. Run the following commands to start the daem process: # start_daem -type standby
----End
4.4 Modifying the Date, Time, and Time Zone on the M2000 Client
This section describes how to modify the date, time, and time zone on the M2000 client running the Windows operating system. You can modify the date, time, and time zone on the M2000 client by modifying the date, time, and time zone of the Windows.
Prerequisite
The Windows operating system is operational.
Procedure
Step 1 Open the Control Panel. This section takes the Windows XP operating system as an example. Step 2 Double-click Date and Time. Step 3 In the Date and Time Properties dialog box, select the items to be modified. Item Hour Minute Second Operation Set the required hour on the Time tab page. Set the required minute on the Time tab page. Set the required second on the Time tab page.
Time Zone Click the Time Zone tab. On the Time Zone tab page, choose the local time zone from the drop-down list. Step 4 Click Apply. ----End
4.5 Configuring the NTP Service of the M2000 (HA)

This section describes how to set the M2000 server in an HA system as the NTP client and synchronize time with the upper-layer server and how to set the M2000 client as the NTP client and synchronize time with the M2000 server. 4.5.1 Checking the Time Settings of the M2000 Server (HA) This section describes how to check the time settings of the M2000 server in an HA system. Before configuring the NTP service of the server, you need to ensure that the time zone, date, and time on node 1 and node 2 are correct. 4.5.2 Setting the M2000 Administration Console as the Secondary NTP Server This section describes how to set the M2000 administration console as the secondary NTP server. The secondary NTP server synchronizes time with the upper-level server and provides a standard time source for a lower-level server. 4.5.3 Starting the NTP Service on the M2000 Administration Console This section describes how to start the NTP service on the M2000 administration console to synchronize the system. 4.5.4 Checking the Running Status of the NTP Service on the M2000 Administration Console This section describes how to check the operational status of the NTP service. 4.5.5 Setting the M2000 Server as an NTP Client (HA system)
This section describes how to set the M2000 HA server as an NTP client to synchronize the clock time with the upper-level server. 4.5.6 Starting the NTP Service on the M2000 Server (HA) This section describes how to start the NTP services on the servers of the M2000 HA system. By performing this task, you can synchronize the server time. 4.5.7 Checking the Running Status of the NTP Service on the M2000 Server (HA) This section describes how to check the running status of the NTP service on the servers of the M2000 HA system. By performing this task, you can ensure that the NTP service is functional. 4.5.8 Setting the NTP Service on the M2000 Client This section describes how to set the M2000 client as the NTP client. This task enables you to synchronize the client with the NTP server through the NTP service of the Windows operating system.
4.5.1 Checking the Time Settings of the M2000 Server (HA)

This section describes how to check the time settings of the M2000 server in an HA system. Before configuring the NTP service of the server, you need to ensure that the time zone, date, and time on node 1 and node 2 are correct.
Procedure
Step 1 Run the following command on both nodes to check the time zone of the system: # echo $TZ If the time zone is set incorrectly on the system that does not use DST, change the time zone by referring to 4.3 Changing the Time Zone of the M2000 Server Without Using DST (HA). Otherwise, change the time zone by referring to 4.6 Setting DST for the M2000 (HA). Step 2 Run the following command on both nodes to check the system date and time: # date If the date is incorrect or the time difference between the clock resource and node 1 or node 2 exceeds two minutes, change the date by referring to 4.2 Modifying the Date and Time on the M2000 Server (HA). ----End
4.5.2 Setting the M2000 Administration Console as the Secondary NTP Server
This section describes how to set the M2000 administration console as the secondary NTP server. The secondary NTP server synchronizes time with the upper-level server and provides a standard time source for a lower-level server.
Prerequisite
l l l
The top layer NTP server has been configured in the mobile network. The time zone, date, and time of the administration console are set correctly. Log in to the administration console as user root through SSH mode.
4-18
Context
Normally, the M2000 server is set as the NTP client. If no other server is available to be set as the secondary time server, use the administration console Netra 240 of the M2000 system as the secondary NTP server. The upper-level time server of the M2000 administration console requires to use the NTP protocol. The server running the Windows operating system uses the SNTP protocol, and thus it cannot function as the the upper-level time server of the M2000 administration console.
Procedure
Step 1 Open the file ntp.conf. # cp /etc/inet/ntp.server /etc/inet/ntp.conf # TERM=vt100; export TERM # vi /etc/inet/ntp.conf Step 2 In front of server 127.127.XType.0, add server IP address of the upper-level NTP server prefer.
NOTE
prefer indicates that the IP address of the NTP server is synchronized preferentially. If multiple upper-level NTP servers exist, write multiple lines. Ensure that each line maps to an NTP server. For example:
server IP address of the upper-level NTP server prefer server IP address of the upper-level NTP server
Step 3 Change XType in server 127.127.XType.0 and fudge 127.127.Xtype.0 stratum 0 to 1. The value 1 indicates that the local host serves as the standard time source. Step 4 In fudge 127.127.1.0 stratum 0, delete stratum 0. Step 5 In front of broadcast 224.0.1.1 ttl 4, add # to comment this line out and to prohibit the broadcasting mode. Step 6 Save the file ntp.conf and quit vi. ----End
Example
To synchronize time with the server whose IP address is 10.161.94.212, you must replace the following contents in the file ntp.conf:
server 127.127.XType.0 fudge 127.127.XType.0 stratum 0 broadcast 224.0.1.1 ttl 4
with:
server 10.161.94.212 prefer server 127.127.1.0 fudge 127.127.1.0 #broadcast 224.0.1.1 ttl 4
Issue 03 (2010-08-31)
4-19
Postrequisite
After setting the M2000 administration console as the secondary NTP server, you need to start the NTP service on the administration console. For details, see 4.5.3 Starting the NTP Service on the M2000 Administration Console.
4.5.3 Starting the NTP Service on the M2000 Administration Console

This section describes how to start the NTP service on the M2000 administration console to synchronize the system.
Prerequisite
l l
The time zone, date, and time of the administration console are correctly set. Log in to the administration console as user root through SSH mode.
Procedure
Step 1 Check whether any NTP service is running. # svcs svc:/network/ntp:default According to the system output, you can check whether the NTP service is started.
l
In the system output, if STATE is disabled, it indicates that the NTP service is not started. Then, perform Step 2 to start the NTP service. In the system output, if STATE is online or maintenance, run the following command to stop the NTP service. Then, perform Step 2 to restart the NTP service. # svcadm disable svc:/network/ntp:default
Step 2 Start the NTP service. # svcadm enable svc:/network/ntp:default

NOTE
This command has the once-for-all effect. The NTP service is started each time the system restarts.
----End
4.5.4 Checking the Running Status of the NTP Service on the M2000 Administration Console
This section describes how to check the operational status of the NTP service.
Context
After the NTP server and the NTP client are started, the system requires five minutes for the system test. Wait for five minutes, and then run the commands ntpq -p and ntptrace to view the status of the NTP service. During the system test, if you run the ntpq -p command, the displayed address of the remote clock source does not contain *. If you run the ntptrace command during the system test, the system displays Timeout or Not Synchronized.
Procedure
Step 1 View the information about the time source. # ntpq -p In the result of the command ntpq -p, the remote field shows the address and status of the reference clock source. Step 2 Check the information about the clock synchronization path. # ntptrace The ntptrace command traces the NTP synchronization path from the host to the top NTP server. For more information, run the command ntptrace -v. ----End
Example
The administration console serves as the medium-level NTP server
root@osssvr # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *10.161.94.212 .LCL. 1 u 165 512 377 0.406 61.294 0.111 +LOCAL(0) LOCAL(0) 3 1 29 64 377 0.000 0.000 0.000 root@osssvr # root@osssvr # ntptrace localhost: stratum 2, offset 0.000039, synch distance 0.07640 10.161.94.212: stratum 1, offset 0.060665, synch distance 0.01015, refid 'LCL' root@osssvr #
In the result of the command ntpq -p, *10.161.94.212 indicates that the IP address of the NTP server that the host is synchronized with is 10.161.94.212. The value 1 in the column st indicates that the host is located at stratum 1. The symbol * indicates that the NTP is running properly. The result of the command ntptrace shows that the host is located at stratum 2, that the IP address of the upper-level server is 10.161.94.212, and that the upper-level server is at stratum 1.
4.5.5 Setting the M2000 Server as an NTP Client (HA system)

This section describes how to set the M2000 HA server as an NTP client to synchronize the clock time with the upper-level server.
Prerequisite
l l
The time zone, date, and time of the server are correctly set. Log in to the active and standby nodes as user root through SSH mode.
Context
The upper-level time server of the M2000 server requires to use the NTP protocol. The server running the Windows operating system uses the SNTP protocol, and thus it cannot function as the upper-level time server of the M2000 server.
Procedure
Step 1 If the M2000 is running, stop the service on the active server. # scswitch -n -j ossapp_rs Step 2 Run the following command on the active and standby nodes and check whether there is any command result: If no system output is displayed, you can infer that the M2000 daemon is terminated. # . /opt/OMC/svc_profile.sh # daem_ps Step 3 If the daemon process is still running, run the following command to forcibly stop it: # kill_daem Step 4 If the Sybase is running, stop the Sybase service on the active node. # scswitch -n -j sybase_rs Step 5 Run the following commands on both the active and standby nodes to check whether the ntp.conf.cluster file is correct: # TERM=vt100; export TERM # vi /etc/inet/ntp.conf.cluster The correct ntp.conf.cluster file should contain the following contents:
peer clusternode1-priv prefer peer clusternode2-priv
If using the NTP server specified by the operator, add a line server XXX.XXX.XXX.XXX before server 127.127.1.0 in the file ntp.conf.cluster. If multiple NTP servers exist, add multiple lines. XXX.XXX.XXX.XXX is the IP address of the NTP server specified by the operator. Replace XXX.XXX.XXX.XXX with the actual IP address. Step 6 If the Sybase is stopped in Step 4, run the following command on either the active node or the standby node to start the Sybase service. # scswitch -e -j sybase_rs Step 7 If the M2000 is stopped in Step 1, run the following command on either the active node or the standby node to start the M2000 service. # scswitch -e -j ossapp_rs Step 8 Run the following command on the standby node to check whether there is any output: # . /opt/OMC/svc_profile.sh # daem_ps
l l
4-22
Issue 03 (2010-08-31)
Step 9 On both the active and standby nodes, check system time and date. # date If system time and date of the two nodes are not consistent, contact Huawei technical support engineers for assistance. ----End
Postrequisite
After setting the M2000 server as the NTP client, you need to start the NTP service on the server. For details, see 4.5.6 Starting the NTP Service on the M2000 Server (HA).
4.5.6 Starting the NTP Service on the M2000 Server (HA)

This section describes how to start the NTP services on the servers of the M2000 HA system. By performing this task, you can synchronize the server time.
Prerequisite
l l
The time zone, date, and time of the M2000 server are set correctly. Log in to node 1 and node 2 as user root through SSH mode.
Procedure
Step 1 On node 1 and node 2, check whether the NTP service is running. # ps -ef | grep ntp
l
If a message similar to the following message is displayed, you can infer that the NTP service is running, perform Step 2 through Step 3 to stop the NTP service.
root 24097 1 ntp.conf.cluster 0 14:38:26 ? 0:00 /usr/lib/inet/xntpd -c /etc/inet/
If a message similar is not displayed, you can infer that the NTP service is stopped.
Step 2 Run the following command on node 1 and node 2, stop the NTP service. # kill -9 Process ID From Step 1, you can determine that the process ID is 24097. To stop the NIP service, run the following command on node 1 and node 2: # kill -9 24097 Step 3 Run the following command on node 1 and node 2 to check whether the NIP service is stopped: # ps -ef | grep ntp If the NTP service is started, repeat Step 2 to Step 3. Step 4 On node 1 and node 2, run the following command to start the NTP service: # /etc/rc2.d/S74xntpd.cluster start ----End
4.5.7 Checking the Running Status of the NTP Service on the M2000 Server (HA)
This section describes how to check the running status of the NTP service on the servers of the M2000 HA system. By performing this task, you can ensure that the NTP service is functional.
Context
The system check requires about five minutes after the NTP server and client are started. After the system check, run the commands ntpq -p and ntptrace to check the status of the NTP service. During this period, run ntpq -p and the displayed address of the remote clock source has no * identifier. Run ntptrace and the system displays Timeout or Not Synchronized.
Procedure
Step 1 Run the following commands on node 1 and node 2 to check the running status of the NTP service. # ntpq -p # ntptrace Step 2 View the results.
l
The remote field in the ntpq -p is the address of the M2000 clock source and displays the status of the clock source. The ntptrace command traces the whole NTP synchronization link to the highest layer from this server. For details, run the command ntptrace -v.
As shown in Figure 4-7, the clock source of the host is a local clock. This host is located in the fourth layer of the NTP. It is normal that Timeout is shown after 127.127.1.0. Figure 4-7 Status of NTP service on node 1
As shown in Figure 4-8, the clock source of the host is node 1 of the Cluster. This host is located in the fifth layer of the NTP and node 1 is located at the fourth layer. It is normal that Timeout is shown after 127.127.1.0.
4-24
Issue 03 (2010-08-31)
Figure 4-8 Status of NTP service on node 2
----End
4.5.8 Setting the NTP Service on the M2000 Client

This section describes how to set the M2000 client as the NTP client. This task enables you to synchronize the client with the NTP server through the NTP service of the Windows operating system.
Prerequisite
l
You have logged in to the Windows operating system. The Windows operating system is running properly. The M2000 client and the M2000 server communicate normally. The clock source of the server is operational.
l l
Context
When the M2000 client is configured as the NTP client, synchronize the time of the M2000 client with the time of the M2000 server. The configuration procedure is applicable to the Windows 2000 Professional, Windows 2003, Windows 2008, Windows XP Professional or Windows Vista Business operating system.
Procedure
Step 1 Configure the M2000 client as the NTP client. Choose Start > Run. In the displayed Run dialog box, enter regedit to open the Registry Editor window. In the registry, choose HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Services > W32Time > Parameters. Then, change the value of the parameter LocalNTP to 0, which is the default value. If the parameter LocalNTP does not exist, it indicates that the value can be ignored and the registry need not be modified.
NOTE
For the operating systems of Windows 2003 or Windows 2008, In the registry, change the value of Enable under HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Services > W32Time > TimeProviders > NtpServer to 0.
Issue 03 (2010-08-31)
4-25
Step 2 Specify the NTP clock source. Choose Start > Run. Type cmd and press Enter. In the displayed window, run the following command: c:\>net time /setsntp:M2000 IP Address of NTP Server
NOTE
1. The result of the net time command is saved in the Windows registry. This setting of the net time takes effect after Windows restarts. 2. To clear the specification, run the net time /setsntp command.
Step 3 Restart the Windows Time service. Choose Start > Run. In the displayed Run dialog box, enter services.msc to open the Services window. Identify the Windows Time service and restart the service. Step 4 Check the NTP server specified by the PC. c:\>net time /querysntp
NOTE
If the host name and IP address of the PC are specified as the host name and IP address of the NTP server by /setsntp, the NTP server time is the local time of the PC.
Step 5 Perform operations based on operating systems.

l l
If the M2000 client runs on Windows 2000 operating system, perform Step 6. If the M2000 client runs on Windows 2003, Windows 2008, Windows XP or Windows Vista operating system, perform Step 7 through Step 8.
Step 6 Run the following command to check the running status of the SNTP: c:\>w32tm -once -v -test The system displays the host name of the connected NTP server, deviation between the local time and the NTP server time, and time cycle of NTP server roll. Step 7 Run the following command to manually synchronize the time: c:\>w32tm /resync Step 8 Run the following command to check the running status of the SNTP: c:\>w32tm /stripchart /computer:IP address of the M2000 server /dataonly The system displays the following information, including the local time of the client and deviation of the local time from that on the NTP server.
Tracking 10.71.15.98 [10.71.15.98]. The current time is 2009-6-22 10:05:09 (local time). 10:05:09, +04.9881239s 10:05:11, +04.9814570s 10:05:13, +04.9740897s 10:05:15, +04.9589559s 10:05:17, +04.9449507s ...
In the system output, the first column displays the local time of the client, and the second column displays the deviation between the local time and the server time. + indicates that the client time
is earlier than the server time. - indicates that the client time is later than the server time. You can press Ctrl+C to exit the browse window. ----End
4.6 Setting DST for the M2000 (HA)

This section describes how to set the time zone of the M2000 server to ensure that DST is supported in an HA system. If DST change occurs on an NE, ensure that the M2000 can handle the data reported by the NE and that no reported data is missing.
Prerequisite
Log in to both nodes as user root through SSH mode by using the corresponding physical IP addresses.
Context
l l
In an HA system, the time zone configurations of both nodes must be the same. On the Solaris operating system, two time formats are available for the time zone: GMT and time zone code. The GMT format stipulates only time offset rather than the DST rules. The time zone code format stipulates the time offset and the DST rules, depending on time zones. The GMT format can be used by the countries and regions that do not use DST. The time zone code format must be used by the countries and regions that use DST. Otherwise, the operating system does not support the automatic DST change. The government may adjust the DST rule of a time zone owing to various reasons. Therefore, you need to query the DST rule of the corresponding time zone based on the time zone code before setting DST. This ensures that the DST rule defined by the time zone code is consistent with the actual DST rule. When the DST rule of a time zone are adjusted, the Sun may release the code patch of this time zone. You can install the code patch to obtain the latest time zone code and DST rule. The setting of the M2000 DST leads to the change of the time at the Solaris bottom layer. In this case, all the timers depending on the operating system are reset or invalidated. To avoid the function failure caused by invalid timers, you need to stop the M2000 and Sybase services before you set the M2000 DST. During this period, the performance data and alarm data of the managed NEs cannot be handled in time. After the M2000 and Sybase services are restored, the M2000 starts the automatic synchronization function, and collects and handles the missing performance data and alarm data from the managed NEs. If you need to set DST and change time, set DST first.
Procedure
Step 1 Query the local time zone name. For details about how to query the name of a time zone name, see 16.1.9 How to Query the Time Zone Name. Step 2 Run the following command to view the DST rule of the time zone in a specified year: # zdump -v time zone name | grep specified year

l
If specified year refers to the current year:
If DST is not used, only a row of information is displayed. If DST is used, five rows of information is displayed for describing the DST rule. The format of the displayed information is as follows:
Time zone name UTC time = local time isdst=0/1
The UTC time is the GMT. isdst=0 stands for being not in the DST period. isdst=1 stands for being in the DST period. If DST is used, four rows of information is displayed for describing the DST rule. If the displayed information does not have four rows, you can infer that DST is not used. The format of the displayed information is as follows:
Time zone name UTC time = local time isdst=0/1
If specified year does not refer to the current year:
The UTC time is the GMT. isdst=0 stands for being not in the DST period. isdst=1 stands for being in the DST period.
If you do not add | grep specified year to the previous command, the system displays the DST rules of the time zone in all years. The DST rule of a time zone stipulates the day, week, and month when DST starts and ends in each year. This means that the week when DST starts is fixed and that the date when DST starts is flexible. For example, DST in the time zone US/Alaska starts from the second Sunday of March and ends on the first Sunday of November in each year. You can run the zdump command to query the DST rules in the three successive years, that is, the last year, this year, and the next year. Based on the system output, you can infer the universal change rules of DST.
NOTE
l l
Step 3 Select different operations based on the DST rule.

l
If the DST rule defined by the time zone code is consistent with the actual DST rule, proceed with Step 4 through Step 15 to set DST. If the DST rule defined by the time zone code is inconsistent with the actual DST rule, obtain and install the latest code patch of the time zone before setting DST.
Step 4 If the M2000 services are running, run the following command on the active node to stop them: # scswitch -n -j ossapp_rs Step 5 Run the following command on the active and standby nodes and check whether there is any command result: If no system output is displayed, you can infer that the M2000 daemon is terminated. # . /opt/OMC/svc_profile.sh # daem_ps Step 6 If the daemon process is still running, run the following command to forcibly stop it: # kill_daem Step 7 If the Sybase services are running, run the following command on the active node to stop the Sybase services:
# scswitch -n -j sybase_rs Step 8 On node 1 and node 2, modify the /etc/TIMEZONE file and change the value of TZ to the name of the required time zone. # TERM=vt100; export TERM # vi /etc/TIMEZONE For example, set TZ to PRC.
NOTE
l l
The time zone configurations of the active and standby nodes must be the same. Query the required time zone in the /usr/share/lib/zoneinfo/src directory. Ensure that the relevant binary time zone file exists in the /usr/share/lib/zoneinfo directory. For example, if you find the local time zone name PRC in the asia file in the /usr/share/lib/zoneinfo/src directory, you need to check whether the binary time zone file /usr/share/lib/zoneinfo/PRC exists. The /etc/TIMEZONE file is read-only. Save the file after modification.
Step 9 Run the following command on the active node to stop the cluster system: # /usr/cluster/bin/scshutdown -g0 -y Step 10 Log in to both servers through the SC, RSC, or XSCF, switches to the ok state. For details, see the M2000 HA System Software Initial Installation Guide (Sun, S10). Step 11 Run the following command to restart the server: ok boot
NOTE
Start node 1 first. Wait for three minutes, and then start node 2.
Step 12 Log in to node 1 and node 2 as user root through SSH mode. Step 13 If the Sybase services are stopped in Step 7, run the following command on node 1 or node 2 to start the Sybase services: # scswitch -e -j sybase_rs Step 14 If the M2000 services are stopped in Step 4, run the following command on node 1 or node 2 to start the M2000 services: # scswitch -e -j ossapp_rs Step 15 Run the following command on the standby node to check whether there is any output: # . /opt/OMC/svc_profile.sh # daem_ps
l l
----End
Example
The query of the DST rules of PRC and US/Alaska in 2007 is taken as an example.
l
Run the following command to view the DST rule of the RPC time zone in 2007: # zdump -v PRC|grep 2007
If the current year is 2007, the system displays only one row of the following information:
PRC Mon Sep 17 06:03:55 2007 UTC = Mon Sep 17 14:03:55 2007 CST isdst=0
If the current year is not 2007, the system does not display any information.
Therefore, you can infer that the PRC time zone does not have DST in 2007.
l
Run the following command to view the rule of the US/Alaska time zone in 2007: # zdump -v US/Alaska|grep 2007
If the current year is 2007, The system displays the following information:
US/Alaska isdst=1 US/Alaska isdst=0 US/Alaska isdst=1 US/Alaska isdst=1 US/Alaska isdst=0 Mon Sep 17 06:09:56 2007 UTC = Sun Sep 16 22:09:56 2007 AKDT Sun Mar 11 10:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 AKST Sun Mar 11 11:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 AKDT Sun Nov Sun Nov 4 09:59:59 2007 UTC = Sun Nov 4 10:00:00 2007 UTC = Sun Nov 4 01:59:59 2007 AKDT 4 01:00:00 2007 AKST
Based on isdst=1 contained in the information in the first row, you can infer that DST is used in US/Alaska. The local time, that is, the DST time, is Sep 16 22:09:56 2007. The UTC time is Sep 17 06:09:56 2007. Based on the information in the second row and the third row, you can infer that DST starts after Mar 11 02:00:00 2007 changes to Mar 11 03:00:00 2007. Based on the information in the fourth row and the fifth row, you can infer that DST ends after Nov 4 02:00:00 2007 changes to Nov 4 01:00:00.
If the current year is not 2007, The system displays the following information:
US/Alaska isdst=0 US/Alaska isdst=1 US/Alaska isdst=1 US/Alaska isdst=0 Sun Mar 11 10:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 AKST Sun Mar 11 11:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 AKDT Sun Nov Sun Nov 4 09:59:59 2007 UTC = Sun Nov 4 10:00:00 2007 UTC = Sun Nov 4 01:59:59 2007 AKDT 4 01:00:00 2007 AKST
Based on the information in the first row and the second row, you can infer that DST starts after Mar 11 02:00:00 2007 changes to Mar 11 03:00:00 2007. Based on the information in the third row and the fourth row, you can infer that DST ends after Nov 4 02:00:00 2007 changes to Nov 4 01:00:00.
4-30
5 Configuring the IP Address of the M2000 Server (HA)
Configuring the IP Address of the M2000 Server (HA)
About This Chapter

This chapter describes how to set the host name and IP address of the server in the M2000 HA system. 5.1 Adding or Deleting a Route of the M2000 Server This section describes how to add or delete a route of the M2000 server. This enables you to set up or delete routes from the local network to multiple target networks. 5.2 Changing the IP Address of the M2000 Server (HA) This section describes how to set the IP network multipathing (IPMP) on the active and standby nodes, how to change the physical IP addresses of the active and standby nodes, and how to change the logical IP address of the HA system. In this case, the IP addresses of the server meet the actual requirements. 5.3 Changing the IP Address of Ethernet Port nxge3 on the M2000 Server (HA) This section describes how to change the IP address of Ethernet port nxge3 on the M2000 server in the HA system to meet the site requirement. 5.4 Modifying the IP Address of the SC or RSC or XSCF on the M2000 Server This section describes how to modify the IP address of the SC/RSC/XSCF on the M2000 server. In special situations, you can log in to the M2000 server through the IP address of the SC/RSC/ XSCF to operate and maintain the server. 5.5 Modifying the IP Address of the Disk Array This section describes how to modify the IP address of the disk array. By modifying the IP address of the disk array, you can maintain the disk array easily.
Issue 03 (2010-08-31)
5-1
5.1 Adding or Deleting a Route of the M2000 Server

This section describes how to add or delete a route of the M2000 server. This enables you to set up or delete routes from the local network to multiple target networks.
Prerequisite
You have logged in to the server as user root in SSH mode.
Context
To add a route to the M2000 server, you must add the route to both nodes.
CAUTION
Run the following command to add a route. After you restart the server, the added route is automatically disabled. # route add Destination network address/mask gateway For example: # route add 129.8.0.0/24 10.12.8.1
Procedure
Step 1 Table 5-1 describes how to add, delete, view, or automatically add a route to the M2000 server. Table 5-1 Adding or deleting a route Operation Adding a route Command # route add Destination network address/mask gateway
l
Example # route add 129.8.0.0/24 10.12.8.1
Destination network address: refers to a network address or a host address. Mask: refers to the number of binary digit 1 in the subnet mask. For example, if the mask is 24, the IP address of the subnet is 255.255.255.0. # route delete 129.8.0.0/24 10.12.8.1 -
Deleting a route Viewing a route
# route delete Destination network address/mask gateway # netstat -rv
5-2
Issue 03 (2010-08-31)
Operation Adding a route automatical ly when the system is restarted
Command Run the following command to create the /etc/rc2.d/S97route file: # vi /etc/rc2.d/S97route Write one or more route add Destination network address/mask gateway commands into the file.
Example route add 129.9.0.1/24 10.12.8.1 route add 129.8.0.0/16 10.12.8.1
----End
5.2 Changing the IP Address of the M2000 Server (HA)

This section describes how to set the IP network multipathing (IPMP) on the active and standby nodes, how to change the physical IP addresses of the active and standby nodes, and how to change the logical IP address of the HA system. In this case, the IP addresses of the server meet the actual requirements.
Context
l
The M2000 HA system provides a logical IP address for the external network. The IP address is automatically assigned to the active server that provides services to the public. The M2000 clients, NEs, and NMS set up communications with the M2000 HA system through the logical IP address of the server. Thus, functions such as data transfer, operation and maintenance are implemented. In the M2000 HA system, the IPMP is already configured before delivery. For example, the model of the server is V890. Network port ce0 is configured as the primary port, and ce2 is configured to provide redundancy. The two network ports are added to the IPMP group. The physical IP addresses of the two network ports share the same physical IP address of the server, thus achieving the redundancy of network ports and guaranteeing the smooth communication between the server and the external network. When other servers are adapted, the IPMP setting is similar with that of the V890 except the network adapter type. The network adapter type varies with the model of the server. For their relation, see the following information. When the OM network requires reparenting, adjustment or reallocation of IP addresses, you need to change the IP address of the M2000 server. You can change the IP address of the server to meet the requirements for network reparenting and adjustment. In this case, the OM network is easily managed and maintained and is more open and flexible. In addition, the scalability and evolution of the network are improved. In the M2000 HA system, the logical IP address of the server and the IPMP configuration and physical IP addresses of the active and standby nodes are stored in the system configuration files of the active and standby nodes. You can run the modify script to modify the relevant configuration files on the active and standby nodes to change the IP address of the server. When you are changing the IP address of the M2000 server, the performance data and alarm data of the managed NEs cannot be processed. If the IP address of the M2000 servers are recorded in the NE database, changing the IP address of the M2000 server leads to the disconnection between the M2000 server and NEs. When changing the IP address of the M2000 server, you need to notify the NE maintenance engineers and ask them to modify
Issue 03 (2010-08-31)
the relevant plans and update the IP address of the M2000 server recorded in the NE database. After you change the IP address of the server, the M2000 collects performance data and alarm data again through automatic synchronization and then processes the data.
l
The M2000 supports both LAN and WAN networking modes. For details, see the M2000 HA System Commissioning Guide (Sun, S10). After the installation and commissioning of the M2000 HA system are complete, osssvr-1 acts as the active node and provides services, and osssvr-2 acts as the standby node.
CAUTION
l
You can run the modify script to change the IP address of the server only when osssvr-1 is the active node and osssvr-2 is the standby node. If the server does not meet the requirement of the active/standby relation, you need to manually adjust the relation. The network adapter type varies with the model of the server. The network adapter of the Netra 240 is bge, the network adapter of the V890 or E4900 is ce, the type of the network adapters used by the T5220 servers is e1000g. When the M4000/M5000 server is used, run the following command: # ifconfig -a | grep e1000g If there is any system output, you can infer that the M4000/M5000 server uses the nxge0 and e1000g0 Ethernet ports. The function of port nxge0 is similar to that of port bge0 of the Netra 240, port ce0 of the V890 or E4900, and port e1000g0 of the T5220; the function of port e1000g0 is similar to that of port bge2 of the Netra 240, port ce2 of the V890 or E4900, and port e1000g2 of the T5220. If there is no system output, you can infer that the M4000/M5000 server uses the bge0 and nxge0 Ethernet ports. The function of port bge0 is similar to that of port bge0 of the Netra 240, port ce0 of the V890 or E4900, and port e1000g0 of the T5220; the function of port nxge0 is similar to that of port bge2 of the Netra 240, port ce2 of the V890 or E4900, and port e1000g2 of the T5220.
Ensure that the IPMP and physical IP addresses of the active and standby nodes and the logical IP address of the HA system are on the same network segment. If you change the IP address of the M2000 server on different network segments, you need to plan and change the physical IP addresses of the active and standby nodes and the logical IP address of the system. In this case, run the modify.sh script to change the IP address of the M2000 server, modify the IP address information in routing devices, and then restart the M2000 server. Before changing the IP address of the server in the M2000 HA system, ensure that the two servers are available and reliable. That is, the Oracle and M2000 services can be started or switched between the active and standby nodes. This section describes how to change the IPMP configuration and physical IP addresses of the active and standby nodes and the logical IP address of the server all at once. If you need to change only some IP addresses of the HA system, perform operations to change only these IP addresses in the relevant steps. The following operations take Ethernet adapter type ce as an example. Replace the network adapter type with the actual type in your on-site operations.
5-4
Issue 03 (2010-08-31)
Procedure
Step 1 Log in to both nodes as user root through SSH mode. Step 2 On either node, run the following command to determine the active and standby nodes: # scstat -D In the system output, the node corresponding to the Primary column is the active node and the node corresponding to the Secondary column is the standby node. This takes osssvr-1 as the active node and osssvr-2 as the standby node as an example.
NOTE
You can run the modify script to change the IP address of the server only when osssvr-1 is the active node and osssvr-2 is the standby node. If the server does not meet the requirement of the active/standby relation, you need to manually adjust the relation. For details, see 3.2.2 Manually Switching Over Active and Standby Nodes (HA).
Step 3 On either node, run the following command to view the /etc/hosts file. You can obtain the IP addresses corresponding to the host names of the two nodes and the IP address corresponding to the name of the logical host in the HA system. # more /etc/hosts If the host name of the active node is osssvr-1, the host name of the standby node is osssvr-2, the name of the logical host of the HA system is osssvr, and the Ethernet adapter type is ce, you need to obtain the IP addresses corresponding to fields osssvr, osssvr-1, osssvr-2, osssvr-1ce0, osssvr-1-ce2, osssvr-2-ce0, and osssvr-2-ce2. Step 4 Run the following command on both nodes to check the IP address of the server: # ifconfig -a In the system output, the system displays the IP addresses obtained in Step 3. These IP addresses are the logical IP address of the HA system and the physical IP addresses and IPMP configuration of the two nodes. Check whether the IP addresses meet the site requirements.
l l
If the IP addresses do not meet the requirements, perform the following steps to change them. If the IP addresses meet the requirements, you need not perform the following steps.
NOTE
Run the ifconfig -a command on the active node, the system displays the logical IP address of the HA system.
Step 5 Check whether the new IP address is already used. This takes the IP addresses shown in Table 5-2 as an example. Table 5-2 Correspondence between the previous and new IP addresses Host Name osssvr osssvr-1 osssvr-2
Issue 03 (2010-08-31)
Previous IP Address 192.168.8.31 192.168.8.11 192.168.8.12

New IP Address 10.10.10.10 10.10.10.11 10.10.10.12

5-5
Host Name osssvr-1-ce0 osssvr-1-ce2 osssvr-2-ce0 osssvr-2-ce2
Previous IP Address 192.168.8.59 192.168.8.60 192.168.8.61 192.168.8.62
New IP Address 10.10.10.40 10.10.10.42 10.10.10.41 10.10.10.43
On the client PC whose IP address is on the same network segment as the new IP address, open the DOS command window and then run the following commands:
l l l l l l l
ping 10.10.10.10 ping 10.10.10.11 ping 10.10.10.12 ping 10.10.10.40 ping 10.10.10.42 ping 10.10.10.41 ping 10.10.10.43
If the IP address can be successfully pinged, you can infer that this IP address is already used and you need to use another one. If the IP address cannot be pinged, you can infer that this IP address is idle and can be used.
NOTE
This section describes how to change the IPMP configuration and the physical IP addresses of the active and standby nodes and the logical IP address of the system. You need to check these IP addresses from Step 3 through Step 5. If you need to change only some IP addresses of the HA system, check only the IP addresses to be changed.
Step 6 If the M2000 services are running, run the following command on the active node to stop them: # scswitch -n -j ossapp_rs Step 7 Run the following command on both nodes to check whether there is any output. If no output exists, you can infer that the M2000 daemon process is stopped. # . /opt/OMC/svc_profile.sh # daem_ps Step 8 If the daemon process continues running, run the following command to stop it: # kill_daem Step 9 Check whether the Sybase services are started. For details, see 16.2.1 How Do I Check Whether the Sybase Is Started. If the Sybase services are not started, start them first. For details, see 16.2.2 How to Start the Sybase (HA, Sun). If the Sybase services are started, perform Step 10.
Step 10 On the active node, namely, osssvr-1, run the modify script to change the IP address of the server.
CAUTION
After being used to change the IP address of the server, the modify script can not be used immediately to modify parameters. You can use the modify script only when the IP addresses take effect after the restart of the server. 1. Run the modify script. The default installation directory of the M2000 server software is /opt/OMC. # . /opt/OMC/svc_profile.sh # cd /opt/OMC/tools/config # ./modify.sh 2. 3. Choose 1--IP. Based on the system prompts, enter the previous and new IP addresses. a. When the system output is similar to the following information, press Enter. The default value in the system output is used.
-----------------------------------------------------------------Note: -- Enter key f/F to finish ip input old-new ip pairs -- Enter key p/P to return pre-step -- Enter key q/Q to exit this tools -----------------------------------------------------------------Please input the old ip[default 192.168.8.31]:
b.
When the system output is similar to the following information, enter the new IP address corresponding to the previous IP address in 10.3.a.
Please input the new ip[default 192.168.8.31]: 10.10.10.10
c.
When the system output is similar to the following information, press Enter. The default value in the system output is used.
Please input the old ip[default 192.168.8.11]:
d.
When the system output is similar to the following information, enter the new IP address corresponding to the previous IP address in 10.3.c.
e.
When the system output is similar to the following information, press Enter. The default value in the system output is used.
Please input the old ip[default 192.168.8.12]:
f.
When the system output is similar to the following information, enter the new IP address corresponding to the previous IP address in 10.3.e.
g.
When the system output is similar to the following information, enter the old IP address corresponding to osssvr-1-ce0.
Please input the old ip: 192.168.8.59
h.
When the system output is similar to the following information, enter the new IP address corresponding to the previous IP address in 10.3.g.
Issue 03 (2010-08-31)
5-7
i.
j.
When the system output is similar to the following information, enter the new IP address corresponding to the previous IP address in 10.3.i.
k.
l.
When the system output is similar to the following information, enter the new IP address corresponding to the previous IP address in 10.3.k.
m. When the system output is similar to the following information, enter the old IP address corresponding to osssvr-2-ce2.
n.
When the system output is similar to the following information, enter the new IP address corresponding to the previous IP address in 10.3.m.
o.
When the system output is similar to the following information, enter f or F. Then, go to the next step.
Please input the old ip: f
NOTE
l l
When running the modify script to change the IP address of the server, if you need to change multiple IP addresses, enter all previous addresses to be changed and their new IP addresses here. When you run the modify script to change the server IP address, the logical IP address of the HA system, and the physical IP addresses of the two nodes, these IP addresses are displayed randomly. This takes changing the logical IP address of the HA system first and then changing the physical IP addresses of the two nodes as an example. During the actual operations, the sequence may differ. Perform the operations according to the actual requirements. If you need not change a certain IP address, press Enter when you are prompted for a new IP address. Then, the default value is used. Enter p or P. The system displays the function menu of the modify script, prompting you to perform operations such as changing the IP address or user password. Enter q or Q to exit the modify script. When the system prompts you to enter the previous IP addresses, enter f or F to finish entering IP addresses and proceed with the next step. This takes changing the logical IP address of the HA system and the physical IP addresses of the two nodes, and setting the IPMP of the two nodes as an example. If you need to change some IP addresses, you need to change the IP addresses to be changed.
l l l l l
4.
Based on the system prompts, enter the password of user sa and then change the subnet mask, and default route. a. When the system displays the following information, enter the password of user sa. This takes emsems as the password of user sa as an example.
-----------------------------------------------------------------Note: -- Enter key p/P to return pre-step -- Enter key q/Q to exit this tools -----------------------------------------------------------------Please input the database superuser's password: emsems
b.
When the system output is similar to the following information, press Enter. The default value in the system output is used as the previous subnet mask.
5-8
Please input the old mask number[default 255.255.255.0]:
c.
When the system output is similar to the following information, enter the new subnet mask. If the subnet mask is not changed, press Enter.
Please input the new mask number[default 255.255.255.0]:
d.
When the system output is similar to the following information, press Enter. The default value in the system output is used as the previous default route.
Please input the old router ip address[default 192.168.8.1]:
e.
When the system output is similar to the following information, enter the new default route.
Please input the new router ip address[default 192.168.8.1]: 10.10.10.1
NOTE
l l l
Enter p or P to return to the previous step. Then, you can perform this step again to reconfigure the relevant parameters. Enter q or Q to exit the modify script. Press Enter. The default values in the system output are used.
5.
The system displays all the parameters that you set. After confirmation, enter Y to apply the changes.
Are you sure to continue? Y--Yes. Q--Quit. R--Re-input P--Return pre-step Please make a choice[Y/Q/R/P]: Y
NOTE
l l l l
Enter Q to exit the script without performing any operations. Enter R to return to Step 10.3. You can reconfigure the relevant parameters. Enter P. The system displays the function menu of the modify script, prompting you to perform operations such as changing the IP address or user password. You need to wait for about three minutes if you run the modify script to change the IP address of the server.
6.
When the change is successful, the system displays the following information and exits the modify script.
-----------------------------------------------------------------Operator complete!
If the system output contains failed, you can infer that the change fails. Contact Huawei technical support engineers for assistance. Step 11 Based on the application scenario, perform the relevant operations. Whether to Change the Server IP Address on Different Network Segments No Yes Procedure
Perform Step 12. Perform Step 13 through Step 18.
Step 12 After restarting the server, check the status of the Sybase and the M2000 services.
CAUTION
If the login fails or the Sybase and M2000 services are exceptional after the server is restarted, contact Huawei technical support engineers for assistance. 1. On the active node, run the following commands to stop the Cluster: # sync; sync; sync; sync; sync; sync # /usr/cluster/bin/scshutdown -g0 -y 2. Log in to both servers through the SC, RSC, or XSCF, switches to the ok state. For details, see the M2000 HA System Software Initial Installation Guide (Sun, S10). 3. Run the following command to restart the servers: ok boot
NOTE
Start node 1 first. Wait for three minutes and then start node 2.
4.
After starting the server, log in to the HA system as user root through SSH mode by using the logical IP address and the physical IP addresses of the active and standby nodes, respectively. If the IP addresses are changed, log in to the HA system by using the new IP addresses. On either node, run the following command to start the Sybase services: # scswitch -e -j sybase_rs
5.
6.
On either node, run the following command to start the M2000 services: # scswitch -e -j ossapp_rs
7.
On the standby node, run the following command to check whether there is any output: # . /opt/OMC/svc_profile.sh # daem_ps
l l
8.
On the active node, check the status of the Sybase and M2000 services. # su - dbuser For details about how to check the status of the Sybase services, see 16.2.1 How Do I Check Whether the Sybase Is Started. -bash-3.00$ exit # . /opt/OMC/svc_profile.sh # svc_adm -cmd status
5-10
Issue 03 (2010-08-31)
Step 13 Modify the gateway address information about the original network segment configured on the route switching device. Step 14 Log in to both servers through the SC, RSC, or XSCF. For details, see the M2000 HA System Software Initial Installation Guide (Sun, S10). Step 15 On the active node, run the following commands to stop the Cluster: # sync; sync; sync; sync; sync; sync # /usr/cluster/bin/scshutdown -g0 -y Step 16 Log in to both servers through the SC, RSC, or XSCF, switches to the ok state. For details, see the M2000 HA System Software Initial Installation Guide (Sun, S10). Step 17 Run the following command to restart the servers: ok boot
NOTE
Start node 1 first. Wait for three minutes and then start node 2.
Step 18 Run the following command to check the status of the Sybase and M2000 services:
CAUTION
If the login fails or the Sybase and M2000 services are exceptional after the server is restarted, contact Huawei technical support engineers for assistance. 1. After starting the server, log in to the HA system as user root through SSH mode by using the new logical IP address and the new physical IP addresses of the active and standby nodes, respectively. On either node, run the following command to start the Sybase services: # scswitch -e -j sybase_rs 3. On either node, run the following command to start the M2000 services: # scswitch -e -j ossapp_rs 4. On the standby node, run the following command to check whether there is any output: # . /opt/OMC/svc_profile.sh # daem_ps
l l
2.
5.
On the active node, check the status of the Sybase and M2000 services. # su - dbuser
Issue 03 (2010-08-31)
5-11
For details about how to check the status of the Sybase services, see 16.2.1 How Do I Check Whether the Sybase Is Started. -bash-3.00$ exit # . /opt/OMC/svc_profile.sh # svc_adm -cmd status ----End
Postrequisite
l
(Optional) If the S2600 disk array is configured and the physical IP addresses of both nodes are configured as the two Trap IP addresses of the S2600 disk array, you need to reconfigure the monitoring function of the S2600 disk array after changing the physical IP address of the active or standby node. For details, see How to Configuring the Monitoring Function of the S2600 Disk Array. You need to reconfigure the two disk arrays. (Optional) If the S3000 series disk array is configured, you need to reconfigure the monitoring function of the disk array after changing the IP address of the server. For details, see 16.1.18 How Should I Configure the Monitoring Function for the S3000 Series Disk Arrays. You need to reconfigure the two series disk arrays.
5.3 Changing the IP Address of Ethernet Port nxge3 on the M2000 Server (HA)
This section describes how to change the IP address of Ethernet port nxge3 on the M2000 server in the HA system to meet the site requirement.
Prerequisite
Log in to the active and standby nodes as user root through SSH mode.
Context
CAUTION
l
If the M4000/M5000 server is used, Ethernet port nxge3 is used to connect disk arrays. The IP address of Ethernet port nxge3 on the active node and the IP address of the disk array must be on the same network segment. If you have changed the IP address of Ethernet port nxge3 on the active node on a different segment, you need to change the IP address of the corresponding disk array to ensure that both changed IP addresses are on the same network segment. Changing the IP address of Ethernet port nxge3 does not affect the database services and the M2000 services. This takes changing the IP address of Ethernet port nxge3 on the osssvr-1 as an example. The method of changing the IP address of nxge3 on the other node is similar.
5-12
Issue 03 (2010-08-31)
Procedure
Step 1 Run the following command on osssvr-1 to change the IP address of Ethernet port nxge3: # ifconfig -a The IP address of Ethernet port nxge3 on the osssvr-1 is displayed in the system output. Check whether it meets the site requirement.
l l
If it does not meet the requirement, you need to perform the following steps to change it. If it meets the requirement, you need not perform the following steps.
Step 2 Check whether the new IP address is use. This takes changing the IP address of Ethernet port nxge3 on osssvr-1 from 192.168.8.241 to 10.10.10.241 as an example. On the client PC whose IP address is on the same network segment as the new IP address, open the DOS command window, and then run the ping 10.10.10.241 command.
l
If the IP address can be successfully pinged, you can infer that this new IP address is already used. In this case, use another IP address. If the IP address cannot be pinged, you can infer that this IP address is idle and can be used.
Step 3 Perform the following steps on the active and standby nodes to change the IP address of Ethernet port nxge3 on osssvr-1: 1. Modify the /etc/hosts file to change the existing IP address of Ethernet port nxge3 on osssvr-1 to a new IP address. # TERM=vt100; export TERM # vi /etc/hosts 2. Run the following command to check the link between the /etc/inet/ipnodes file and the / etc/inet/hosts file: # ls -al /etc/inet/ipnodes
l
If /etc/inet/ipnodes -> ./hosts is contained in the system output, you can infer that the two files are linked. Then, proceed with Step 3.3. If /etc/inet/ipnodes -> ./hosts is not contained in the system output, you can infer that the files are not linked. Then, perform Step 3.4.
3.
Run the following command to check the link between the /etc/hosts file and the /etc/inet/ hosts file: # ls -al /etc/hosts
l
If /etc/hosts -> ./inet/hosts is contained in the system output, you can infer that the two files are linked, that is, the /etc/hosts file and the /etc/inet/ipnodes file are linked. Then, perform Step 4. If /etc/hosts -> ./inet/hosts is not contained in the system output, you can infer that the two files are not linked, that is, the /etc/hosts file and the /etc/inet/ ipnodes file are not linked. Then, perform Step 3.4.
4.
Modify the /etc/inet/ipnodes file to change the existing IP address of Ethernet port nxge3 on osssvr-1 to a new IP address.
Issue 03 (2010-08-31)
# vi /etc/inet/ipnodes Step 4 On osssvr-1, modify the /etc/hostname.nxge3 file to change the exiting IP address of Ethernet port nxge3 on the active node to a new IP address. # vi /etc/hostname.nxge3
NOTE
l l
If this file records the information about host names, do not modify this file. In the /etc/hostname.nxge3 file, no space is allowed at the beginning of each line of content.
Step 5 Run the following command on osssvr-1 for the new IP address of Ethernet port nxge3 to take effect: # ifconfig nxge3 10.10.10.241 netmask 255.255.255.0 up ----End
5.4 Modifying the IP Address of the SC or RSC or XSCF on the M2000 Server
This section describes how to modify the IP address of the SC/RSC/XSCF on the M2000 server. In special situations, you can log in to the M2000 server through the IP address of the SC/RSC/ XSCF to operate and maintain the server. 5.4.1 Modifying the IP Address of the SC on the Netra 240 Server This section describes how to modify the IP address of the SC on the Netra 240 server to comply with the specification. 5.4.2 Changing the IP Address of the RSC on the V890 Server This section describes how to change the IP address of the RSC on the V890 server. 5.4.3 Modifying the IP Address of the SC on the E4900 Server This section describes how to modify the IP address of the SC on the E4900 server so that the new IP address complies with the specification. The IP address of the SC on the E4900 server can be the IP address of the standby SC1 or the IP address of the active SC0. 5.4.4 Modifying the IP Address of the SC on the T5220 Server This section describes how to change the IP address of the SC on the T5220 server to ensure that the IP address meet the requirement. 5.4.5 Changing the IP Address of the XSCF on the M4000/M5000 Server This section describes how to change the IP address of the XSCF on the M4000/M5000 server to meet the actual requirements.
5.4.1 Modifying the IP Address of the SC on the Netra 240 Server

This section describes how to modify the IP address of the SC on the Netra 240 server to comply with the specification.
Prerequisite
l
The PC terminal and the interface of the SC on the server communicate normally.
5-14

l l
The password for user admin of the SC is available. The new IP address of the SC is planned.
Procedure
Step 1 Run the following command on the PC terminal to establish the connection between the PC and the SC: telnet original IP address of SC
NOTE
If the PC and SC cannot be connected by running the telnet command, connect them through a serial port cable. For details, refer to M2000 Software Initialization Installation Guide (Sun,S10).
Step 2 Log in to the SC as user admin. Step 3 Set the new IP address and the subnet mask for the SC on the server. sc> setsc netsc_ipaddr new IP address of SC sc> setsc netsc_ipnetmask subnet mask of SC sc> setsc netsc_ipgateway gateway address of the SC Step 4 To restart the SC on the server, run the following command: sc> resetsc ----End
5.4.2 Changing the IP Address of the RSC on the V890 Server

This section describes how to change the IP address of the RSC on the V890 server.
Prerequisite
l l l
The network communication between the PC terminal and the RSC server is normal. You have obtained the password of the RSC user admin. A new IP address of the SC is planned.
Procedure
Step 1 Run the following command on the PC terminal to establish the connection between the PC and the RSC: telnet original IP address of RSC Step 2 Log in to the RSC and run the following commands to change the IP address of RSC: rsc> set ip_mode config rsc> set ip_addr X.X.X.X rsc> set ip_netmask X.X.X.X rsc> set ip_gateway X.X.X.X

NOTE
l l l
In ip_addr X.X.X.X, X.X.X.X indicates a new IP address planned for the RSC. In ip_netmask X.X.X.X, X.X.X.X indicates a new subnet mask planned for the RSC. In ip_gateway X.X.X.X, X.X.X.X indicates a new gateway planned for the RSC.
Step 3 Restart the RSC for the modification to take effect. rsc> resetrsc When the system prompts the following message, type y for confirmation.
Are you sure you want to reboot RSC (Yes/No)?
----End
5.4.3 Modifying the IP Address of the SC on the E4900 Server

This section describes how to modify the IP address of the SC on the E4900 server so that the new IP address complies with the specification. The IP address of the SC on the E4900 server can be the IP address of the standby SC1 or the IP address of the active SC0.
Prerequisite
l
The PC terminal communicates normally with the ports of the standby SC1 and the active SC0. The two new IP addresses of the SC are planned.
Procedure
Step 1 Change the IP address of the standby SC1. 1. Run the following command on the PC terminal to establish the connection between the PC and the SC1: telnet original IP address of SC1
NOTE
If the PC and SC1 cannot be connected by the telnet command, connect them through a serial port cable. For details, refer to M2000 Software Initialization Installation Guide (M4000/M5000, S10).
2. 3.
Log in to the SC as user admin. Set the parameters for the standby controller. :sc> setupplatform
NOTE
When using the command setupplatform to change the IP address of SC1, you also need to enter parameters such as the host name of SC1. If you need to modify only the IP address of the SC1, retain the original settings of other parameters.
4.
Change the IP address of SC1 according to Table 5-3. When the system displays any parameter that is not listed in Table 5-3, press Enter to continue.
5-16
Issue 03 (2010-08-31)
Table 5-3 Parameters for the standby controller Parameter

Use DHCP or static network settings? [DHCP]:
Value static Retain the host name of SC1 Enter the new IP address of SC1 Enter the actual subnet mask, if required Enter the IP address of the actual gateway, if required yes
Hostname IP Address Netmask Gateway Enable SC Failover? [no]:
5.
Restart the backup SC1. :sc> reboot When the system prompts the following message, enter y, and then press Enter.
Are you sure you want to reboot the system controller now? [no]
NOTE
l l
When the system prompts other messages, retain the default settings and press Enter. Restarting SC1 takes some time. You need to wait for a while.
When the system displays osssvr-1-sc1:sc>, you can infer that the controller is restarted. The osssvr-1-sc1 is the host name of SC1. Step 2 Change the IP address of the active SC0. 1. Run the following commands on the PC terminal to establish the connection between the PC and the SC0. telnet original IP address of SC0
NOTE
If the PC and SC0 cannot be connected by the telnet command, connect them through a serial port cable. For details, refer to M2000 Software Initialization Installation Guide (M4000/M5000, S10).
2.
Configure the parameters for the active controller. :SC> setupplatform

NOTE
When using the setupplatform command to change the IP address of SC0, you also need to enter parameters such as the host name of SC0. If you need to modify only the IP address of the SC0, retain the original settings of other parameters.
3.
Change the IP address of SC0 according to Table 5-4. When the system prompts any parameter that is not listed in Table 5-4, press Enter to continue.
Issue 03 (2010-08-31)
5-17
Table 5-4 Parameters for the standby controller Parameter

Use DHCP or static network settings? [DHCP]:
Value static Retain the host name of SC0 Enter the new IP address of SC0 Enter the actual subnet mask, if required Enter the IP address of the actual gateway, if required yes telnet Retain the logical host name of the SC
Hostname IP Address Netmask Gateway Enable SC Failover? [no]:

Connection type (ssh, telnet, none) [telnet]: Logical Hostname or IP Address [ ]:
4.
Restart the backup SC0. :SC> reboot When the system prompts the following message, enter y, and then press Enter.
Are you sure you want to reboot the system controller now? [no]
NOTE
l l
When the system prompts other messages, keep the default settings and press Enter. Restarting SC1 takes some time. You need to wait for a while.
When the system displays osssvr-1-sc0:SC>, you can infer that the controller is restarted. The name osssvr-1-sc0 is the host name of SC0. ----End
5.4.4 Modifying the IP Address of the SC on the T5220 Server

This section describes how to change the IP address of the SC on the T5220 server to ensure that the IP address meet the requirement.
Prerequisite
l l l
The PC terminal and the network port of the SC on the server communicate well. The password for user admin of the SC is available. The new IP address of the SC is planned.
Procedure
Step 1 Start the PuTTY on the PC terminal and set up the connection between the PC and the SC based on the SSH protocol.
In the window of the PuTTY Configuration, select SSH, enter IP address of the SC in Host Name (or IP Address), and click Open to log in to the SC.
NOTE
l l
Log in to the http://support.huawei.com to download the PuTTY to the PC. If the PC and SC cannot be connected through the PuTTY, connect them by using a serial port cable. For details, refer to the corresponding Software Initialization Installation Guide.
Step 2 Enter the user name admin and the password to log in to the SC. The sc> prompt is displayed. Step 3 Set the new IP address and the subnet mask for the SC on the server. sc> setsc netsc_ipaddr new IP address of the SC sc> setsc netsc_ipnetmask subnet mask of the SC sc> setsc netsc_ipgateway IP address of the SC gateway Step 4 Run the following command to change the IP address and subnet mask of the SC: sc> setsc netsc_commit true ----End
5.4.5 Changing the IP Address of the XSCF on the M4000/M5000 Server

This section describes how to change the IP address of the XSCF on the M4000/M5000 server to meet the actual requirements.
Prerequisite
l l l
The communication between the PC and port 0 on the XSCF is normal. The password of user adminuser is available. A new IP address of the XSCF is planned.
Context
l l
Port 0 and port 1 on the XSCF are independent of each other. When the M4000/M5000 server is used as the M2000 server, port 0 on the XSCF is used for networking. Thus, you need to use the IP address of port 0 to log in to the XSCF.
Procedure
Step 1 Start the PuTTY on the PC and log in to the XSCF of the server through the telnet.
Issue 03 (2010-08-31)
5-19

NOTE
l l l l
To log in to the XSCF of the M4000/M5000 server, use the IP address of port 0 on the XSCF. Log in to the http://support.huawei.com to download the PuTTY to the PC. For details about how to log in to the XSCF through the PuTTY, see the corresponding M2000 Software Initialization Installation Guide. If the PC and XSCF cannot be connected by running the telnet command, connect them through a serial port cable. For details, see the corresponding M2000 Software Initialization Installation Guide.
Step 2 Log in to the XSCF as user adminuser. Step 3 Run the following command to change the IP address of the XSCF. XSCF> setupplatform Step 4 When the system displays Do you want to set up an account? [y|n]:, type n, and then press Enter. Step 5 When the system displays Do you want to set up networking? [y|n]:, type y, and then press Enter. Step 6 When the system displays Do you want to set up the XSCF network interfaces? [y|n]:, type y, and then press Enter. Step 7 Set the IP address, subnet mask, and gateway IP address of xscf#0-lan#0. 1. 2. When the system displays Do you want to configure xscf#0-lan#0? [y| n]:, type y. When the system displays the following prompt, enter the IP address, subnet mask, and gateway IP address of port 0 on the XSCF according to the planning:
xscf#0-lan#0 ip address? []: xscf#0-lan#0 netmask? [255.255.255.0]: xscf#0-lan#0 default gateway? []:
3.
Check the entered information.

xscf#0-lan#0 ip address: X.X.X.X xscf#0-lan#0 netmask: X.X.X.X xscf#0-lan#0 default gateway: X.X.X.X Are these settings correct? [y|n]: y
NOTE
l l l
In xscf#0-lan#0 ip address: X.X.X.X, X.X.X.X indicates a new IP address planned for port 0 on the XSCF. In xscf#0-lan#0 netmask: X.X.X.X, X.X.X.X indicates a new subnet mask planned for port 0 on the XSCF. In xscf#0-lan#0 default gateway: X.X.X.X, X.X.X.X indicates a new gateway IP address planned for port 0 on the XSCF.
Step 8 When the system displays Do you want to configure xscf#0-lan#1? [y| n]: , type n. Step 9 When the system displays Do you want to configure lan#0? [y|n]:, type n. Thus, you need not configure the take over function for network adapter 0. Step 10 When the system displays Do you want to configure lan#1? [y|n]:, type n. Thus, you need not configure the take over function for network adapter 1.
Step 11 When the system displays Do you want to set up the DSCP network? [y| n]:, type n. Thus, you need not configure the DSCP protocol. Step 12 When the system displays Do you want to set up the domain name service? [y|n]:, type n. Step 13 When the system displays Do you want to set up the network time protocol? [y|n]:, type n. Thus, you need not configure the NTP service. Step 14 When the system displays Do you want to set up ssh? [y|n]:, type n. Thus, you need not configure the SSH protocol. Step 15 When the system displays Do you want to set up https? [y|n]:, type n. Then, the https will not be enabled. Step 16 When the system displays Do you want to configure email reports? [y| n]:, type n. Then, the email function will not be enabled. Step 17 When the system displays Do you want to apply the network changes? [y| n]:, type y. Step 18 Check the network configuration information about the XSCF.
The following network settings will be applied: xscf#0 hostname :osssvr-1-xscf0 DNS domain name : interface status IP address netmask route interface status IP address netmask route Continue? [y|n] :y :xscf#0-lan#0 :up :X.X.X.X :X.X.X.X :-n 0.0.0.0 -m 0.0.0.0 -g X.X.X.X :xscf#0-lan#1 :up :192.168.9.141 :255.255.255.0 :-n 0.0.0.0 -m 0.0.0.0 -g 192.168.9.254
Step 19 When the system displays Do you want to reboot the XSCF now? [y|n]:, type y. Then, the XSCF automatically restarts. ----End
5.5 Modifying the IP Address of the Disk Array

This section describes how to modify the IP address of the disk array. By modifying the IP address of the disk array, you can maintain the disk array easily. 5.5.1 Modifying the IP Address of the 3320 Disk Array This section describes how to modify the IP address of the 3320 disk array. To perform this task, you need to log in to the 3320 disk array through PC or administration console. Normally, you need not change the IP address of the disk array because the disk array is connected to the server directly through optical fibers. In addition, change of IP addresses does not affect data read and write operations on the disk array. Generally, use the factory default IP address of the disk array. If the IP address of a disk array needs to be changed, change the IP address according to the actual situation.
5.5.2 Changing the IP Address of the S3X00 Series Disk Array (Serial Port Mode) This section describes how to change the IP address of the S3X00 disk array. Normally, you need not change the IP address of the disk array because the disk array is connected to the server directly through optical fibers. In addition, change of IP addresses does not affect data read and write operations on the disk array. Generally, use the factory default IP address of the disk array. If the IP address of a disk array needs to be changed, change the IP address according to the actual situation.The IP address of each S3X00 disk array needs to be changed. 5.5.3 Changing the IP Address of the 6140 Disk Array (Serial Port Mode) This section describes how to change the IP address of the 6140 disk array. Normally, you need not change the IP address of the disk array because the disk array is connected to the server directly through optical fibers. In addition, changing IP addresses does not affect data read operations on the disk array. Generally, you need to use the factory default IP address of the disk array. If the IP address of a disk array needs to be changed, you need to change the IP address according to the actual situation. You need to configure each 6140 disk array. 5.5.4 Changing the IP Address of the S2600 Disk Array (Serial Port Mode) This section describes how to change the IP address of an S2600 disk array in serial port mode. The disk array is connected to the server directly through optical fibers. Therefore, changing the IP address of the disk array does not affect data read operations on the disk array. It is strongly recommended that you retain the default IP address of the disk array. If you need to change the IP address of the disk array, change it according to the actual situation. You need to configure each S2600 disk array.
5.5.1 Modifying the IP Address of the 3320 Disk Array

This section describes how to modify the IP address of the 3320 disk array. To perform this task, you need to log in to the 3320 disk array through PC or administration console. Normally, you need not change the IP address of the disk array because the disk array is connected to the server directly through optical fibers. In addition, change of IP addresses does not affect data read and write operations on the disk array. Generally, use the factory default IP address of the disk array. If the IP address of a disk array needs to be changed, change the IP address according to the actual situation.
Prerequisite
l l
The SUNWsscs software has been installed on the server. All the IO operations related to the disk array have been stopped.
Procedure
Step 1 To modify the IP address of the 3320 disk array, run the following command: # sccli sccli > configure network-interface lan0 ip-address IP address netmask Subnet mask gateway Gateway address Take the setting of the IP address for the 3320 disk array to 192.168.8.39 as an example. Supposing the subnet mask is 255.255.255.0 while the gateway address is 192.168.8.1, run the following command: sccli > configure network-interface lan0 ip-address 192.168.8.39 netmask 255.255.255.0 gateway 192.168.8.1 Then, the following message is displayed:
sccli changes will not take effect until controller is reset
Step 2 To restart the controller, run the following command: sccli > reset controller Step 3 When the system displays the following prompt, enter y.
Are you sure?
Step 4 (Optional) Modify the /etc/hosts file and the /etc/inet/ipnodes file of the two nodes.
NOTE
To change the disk array IP address recorded in the /etc/hosts file and the /etc/inet/ipnodes file, you need not stop the M2000 services and the database services. After the modification, you need not restart the server either.
1. 2.
You have logged into both the nodes as user root. Perform the following operations on both the nodes to modify the /etc/hosts file and to replace the existing IP address of the disk array with a new one. # vi /etc/hosts After the modification, press Esc and then run the :wq! command to save the modification and exit.
3.
Perform the following operations on both the nodes to modify the /etc/inet/ipnodes file. # vi /etc/inet/ipnodes
l
If the file records the existing IP address of the disk array, replace the existing IP address with the new one. After the modification, press Esc and then run the :wq command to save the modification and exit. If the file records the new IP address of the disk array, you need not perform any modification. Press Esc and then run the :q command to exit.
----End
5.5.2 Changing the IP Address of the S3X00 Series Disk Array (Serial Port Mode)
This section describes how to change the IP address of the S3X00 disk array. Normally, you need not change the IP address of the disk array because the disk array is connected to the server directly through optical fibers. In addition, change of IP addresses does not affect data read and write operations on the disk array. Generally, use the factory default IP address of the disk array. If the IP address of a disk array needs to be changed, change the IP address according to the actual situation.The IP address of each S3X00 disk array needs to be changed.
Prerequisite
Context
Each S3X00 disk array has two controllers and each controller has two ports. To change the IP address of the controller, you need to change only port 1 on the controller. Retain port 2 for future use.
If the M4000/M5000 server is used, Ethernet port nxge3 is used to connect the server and a disk array. Thus, the IP address of Ethernet port nxge3 and the IP address of the disk array must be on the same network segment. If you have changed the IP address of the disk array on a different segment, you need to change the IP address of the corresponding Ethernet port nxge3 to ensure that both changed IP addresses are on the same network segment.
Procedure
Step 1 Use the serial port cable to connect the serial port of the controller of the disk array and that of the PC. Figure 5-1 shows the disk array. Figure 5-1 Serial ports of the S3X00
NOTE
You must use the serial port cable that is delivered with the disk array rather than the serial port cable of other devices. The serial port cable delivered with the disk array is special for the storage device. If you do not use this serial port, the communication may fail. A DB-9 connector at one end of the serial port cable is connected to the serial port on the PC. A 6-thread round connector at the other end is connected to the port of the disk array controller. You need to configure the controller that is connected to the serial port (Controller A is on the left while controller B is on the right.)
Step 2 Choose Start > Programs (P) > Accessories > Communications > HyperTerminal. Step 3 In the Connection Description dialog box, enter a name for the new connection. Step 4 Specify a serial port of the PC terminal to connect to the disk array. Step 5 Set the properties of the serial port. For details about how to set the properties of a serial port, see Table 5-5. Then, click OK. Table 5-5 Setting properties of the serial port Property Bits per second Data bits Parity Stop bits
5-24
Value 9600/38400 8 Null 1

Property Data stream control
Value Null
Step 6 Press Ctrl+Break to activate Shell of the serial port. Step 7 If the following information is displayed in the HyperTerminal window, enter Esc within five seconds. The Shell Login interface is displayed.
Press within 5 seconds: <S>for Service Interface , <BREAK>for band rate
Step 8 If the following information is displayed, enter the login password infiniti and press Enter to log in to the disk array and to configure Shell.
Enter password to access shell:
Step 9 Run the following command to check the port configuration of the controller that you have logged in to. -> netCfgShow Figure 5-2 shows the port configuration of the controller that you have logged in to. Figure 5-2 Checking the port configuration
Table 5-6 shows the main configuration items in Figure 5-2. Table 5-6 Configuration items of the controller port Configuration Item IP Address if0 Meaning Indicates the IP address of port if0 of the controller that you have logged in to.
Issue 03 (2010-08-31)
Configuration Item Subnet Mask if0 Gateway IP Address
Meaning Indicates the subnet mask of port if0 of the controller. Indicates the gateway IP address.
If the port configuration of the controller meets the specifications, you need not perform any operation. If the port configuration of the controller does not meet the specifications, perform the following operation to change it.
Step 10 Run the following command: -> netCfgSet The system output is similar to the message shown in Figure 5-3. Press Enter. Figure 5-3 Port configuration (I)
Step 11 Set the IP address of port if0 of the controller. This takes 192.168.8.39 as an example to describe how to change the IP address of port if0. After typing the new IP address, press Enter, as shown in Figure 5-4. Figure 5-4 Port configuration (II)
NOTE
l l
If you press Enter without typing a new IP address, the original IP address retains. To restore the IP address of port if0 to the default value predefined before delivery, enter "." and then press Enter.
Step 12 Set the subnet mask of port if0 of the controller.

In the output information shown in Figure 5-5, type the new subnet mask and then press Enter. If you press Enter without typing a new subnet mask, the original one retains. To restore the subnet mask of port if0 to the default value predefined before delivery, enter "." and then press Enter. Figure 5-5 Port configuration (III)
Step 13 The output information is similar to the following message. Press Enter. The IP address of port if1 is not changed.
IP Address if1 : 192.168.129.101
Step 14 The output information is similar to the following message. Press Enter. The subnet mask of port if1 is not changed.
Subnet Mask if1 : 255.255.255.0
Step 15 The system displays the following message. Press Enter.

Server Host Name :
Step 16 The system displays the following message. Press Enter.

Server IP Address :
Step 17 Set the gateway IP address. This takes 192.168.8.39 and 255.255.255.0 as an example to describe how to change the IP address and subnet mask of port if0. After typing in the new gateway IP address 192.168.8.1, press Enter, as shown in Figure 5-6. Figure 5-6 Port configuration (IV)
l l
If you press Enter without typing a new gateway IP address, the original one retains. To restore the gateway IP address to the default value predefined before delivery, enter "." and then press Enter.
: 0xA0
Step 18 When the system displays the following message, press Enter.
Network Init Flags
User Name :
User Password :
Step 21 When the system displays the following message, then the IP address of the controller that you have logged in to is successfully changed.
Network Configuration successfully written to NVSRAM.
Step 22 Run the following command to check whether the information about the port of the disk array is correctly changed. -> netCfgShow

l
If the port information is incorrect, perform the previous steps to change it. Then, perform Step 23. If the port information is correct, perform Step 23.
Step 23 Check whether the new IP address of the controller takes effect. On the client PC whose IP address is in the same network segment as the new IP address, open the DOS command window and then run the ping New IP address of the disk array controller command.
l l
If you successfully ping the IP address, then the new IP address takes effect. If you fail to ping the IP address, contact Huawei technical support engineers for assistance.
Step 24 Connect the serial port cable to the port of controller B. Perform the previous steps to change the port IP address of the other controller. Step 25 (Optional) Modify the /etc/hosts file and the /etc/inet/ipnodes file of the two nodes.
NOTE
1. 2.
Log into both the nodes as user root through SSH mode. Perform the following operations on both the nodes to modify the /etc/hosts file and to replace the existing IP address of the disk array with a new one. # vi /etc/hosts After the modification, press Esc and then run the :wq! command to save the modification and exit.
3.
Perform the following operations on both the nodes to modify the /etc/inet/ipnodes file. # vi /etc/inet/ipnodes
l
----End
Postrequisite
(Optional) After changing the IP address of the S3X00 disk array, you need to reconfigure the monitoring function of the disk array. For details, see 16.1.18 How Should I Configure the Monitoring Function for the S3000 Series Disk Arrays in the corresponding Administrator Guide. You need to reconfigure the two series disk arrays.
5.5.3 Changing the IP Address of the 6140 Disk Array (Serial Port Mode)
This section describes how to change the IP address of the 6140 disk array. Normally, you need not change the IP address of the disk array because the disk array is connected to the server directly through optical fibers. In addition, changing IP addresses does not affect data read
operations on the disk array. Generally, you need to use the factory default IP address of the disk array. If the IP address of a disk array needs to be changed, you need to change the IP address according to the actual situation. You need to configure each 6140 disk array.
Context
The 6140 disk array has two controllers. Each controller has two Ethernet ports. When you change the IP address of a controller, only Ethernet port 1 needs to be modified. Ethernet port 2 is reserved for maintenance. If the M4000/M5000 server is used, Ethernet port nxge3 is used to connect the server and a disk array. Thus, the IP address of Ethernet port nxge3 and the IP address of the disk array must be on the same network segment. If you have changed the IP address of the disk array on different network segments, you need to change the IP address of the corresponding Ethernet port nxge3 to ensure that both of the changed IP addresses are on the same network segment.
Procedure
Step 1 Connect the 6-pin mini DIN connector of the basic cable to the serial port connector of controller A. Figure 5-7 shows the disk array. Figure 5-7 Serial ports of the 6140 disk array
NOTE
Two serial port cables are attached to the pallet of each controller.
l l
One end is the 6-pin mini DIN connector, and the other end is the basic cable of the standard 9-pin serial port connector. Extended cables of the standard 9-pin serial port connector are attached to both ends.
Step 2 Connect the 9-pin serial extended cable from the 9-pin connector of the basic cable to the serial port connector of the PC. Step 3 Choose Start > Programs (P) > Accessories > Communications > HyperTerminal on the PC. Step 4 In the Connection Description dialog box, enter a name for the new connection. Step 5 Choose the PC serial port that connects to the connector, for example, COM1. Step 6 Set the properties of the serial portaccording to Table 5-7. Then, click OK.
Table 5-7 Setting properties of the serial port Property Bits per second Data bits Parity Stop bits Data stream control Value 38400 8 Null 1 Null
After the connection is complete, a physical connection between the PC and the 6140 disk array is set up. Step 7 Press Ctrl+Break. The serial port responses with a request so that the baud rate can be synchronized with that on the PC.
Set baud rate: press <space> within 5 seconds
NOTE
The serial ports on the disk array request that Break be accepted. Set the corresponding escape sequence for the terminal configuration, and then send the essential Break to the controller of the disk array. For instance, press Ctrl and Break at the same time to generate the Break character on certain terminals.
Step 8 Press the spacebar within five seconds. The serial port The serial port check the baud rate set up for the connection.
Baud rate set to 38400
Step 9 Press Ctrl+Break. The serial port responds with the following information:
Press within 5 seconds: <S> for Service Interface, <BREAK> for baud rate
Step 10 Press S. The system prompts you to enter a password.
CAUTION
S must be in upper case.
Enter Password to access Service Interface (60 sec timeout): - >
Step 11 Enter the password kra16wen, and then press Enter. Step 12 If the following information is displayed, type 2.
Service Interface Main Menu ============================== 1 Display IP Configuration 2 Change IP Configuration 3 Reset Storage Array (SYMbol) Password Q Quit Menu Enter Selection:
Step 13 If the following information is displayed, type 1.

Select Ethernet Port ==============================
5-30
Issue 03 (2010-08-31)

1 Ethernet Port: 0 2 Ethernet Port: 1 Q Quit Enter Selection: 1
Step 14 If the following information is displayed, type n. The DHCP function is not used to configure the dynamic IP address for the port.
Configure using DHCP ? (Y/N): n
Step 15 If the following information is displayed, enter the IP address of controller A and its subnet mask.
NOTE
The subnet mask is optional.

Press '.' to clear the field; Press '-' to return to the previous field; Press <ENTER> and then ^D to quit (Keep Changes) Current Configuration New Configuration IP Address if1 : 192.168.128.101 IP-address Subnet Mask if1 : 255.255.255.0 <ENTER>
After the configuration, the system displays the information about the specified IP address. Step 16 If the following information is displayed, type 1.
Step 17 If the following information is displayed, type 1.

Select Ethernet Port ============================== 1 Ethernet Port: 0 2 Ethernet Port: 1 Q Quit Enter Selection: 1
The IP address of the selected Ethernet port is displayed. Check whether the changed IP address is correct again. If the changed IP address is incorrect, perform Step 12 through Step 17 to configure the IP address of the controller again. Step 18 If the following information is displayed, enter Q to exit.
Step 19 Perform Step 1 through Step 18 again to change the IP address of control B in the same way. Step 20 (Optional) Modify the /etc/hosts file and the /etc/inet/ipnodes file of the two nodes.
NOTE
1.
Issue 03 (2010-08-31)
Log in to both nodes as user root.

2.
Perform the following operations on both nodes to modify the /etc/hosts file and to replace the existing IP address of the disk array with a new one: # vi /etc/hosts After the modification, press Esc, and then run the :wq! command to save the modification and exit.
3.
Perform the following operations on both nodes to modify the /etc/inet/ipnodes file: # vi /etc/inet/ipnodes
l
If the file records the existing IP address of the disk array, replace the existing IP address with the new one. After the modification, press Esc, and then run the :wq command to save the modification and exit. If the file records the new IP address of the disk array, you need not perform any modification. Press Esc, and then run the :q command to exit.
----End
5.5.4 Changing the IP Address of the S2600 Disk Array (Serial Port Mode)
This section describes how to change the IP address of an S2600 disk array in serial port mode. The disk array is connected to the server directly through optical fibers. Therefore, changing the IP address of the disk array does not affect data read operations on the disk array. It is strongly recommended that you retain the default IP address of the disk array. If you need to change the IP address of the disk array, change it according to the actual situation. You need to configure each S2600 disk array.
Context
l
Each S2600 disk array has an active controller and a standby controller. Each controller has a CLI serial port. You can change the IP address in serial port mode or command mode. The serial port mode is preferred because it features high success rate in changing IP addresses. In the case of remote operations, use the command mode. For details, see 16.1.13 How Do I Change the IP Address of the S2600 Disk Array (Command Mode). Before changing the IP address, you must familiarize yourself with the default IP address planning at delivery. Then, determine whether to re-set the IP address according to the actual situation. The IP address mentioned here is only an example. Replace it with the actual IP address. If you change the IP addresses of disk arrays on different network segments, change the IP address of the maintenance Ethernet port on the corresponding server to ensure that two changed IP addresses are on the same network segment.
l l
Procedure
Step 1 Use the serial port cable to connect any serial port on the controller of the disk array and that of the PC. Figure 5-8 shows the disk array.
5-32
Issue 03 (2010-08-31)
Figure 5-8 Serial ports provided by the S2600 disk array
NOTE
l l
You need to use the serial port cable that is delivered with the disk array. Otherwise, the disk array may fail to be connected. When using the serial port cable to connect a control to the maintenance terminal, you must use the serial port cable to connect the maintenance terminal first. When disconnecting the control from the maintenance terminal, you must remove the serial port cable from the control first. After using the serial port cable to connect a controller to the maintenance terminal, do not enable the control and the maintenance terminal at the same time. After using the DB9-RJ45 serial port cable to connect a controller and the maintenance terminal, you need to use the HyperTerminal or any other program provided by the Windows operating system to log in to the CLI serial port.
l l
Step 2 Choose Start > Programs (P) > Accessories > Communications > HyperTerminal on the PC. Step 3 In the Connection Description dialog box, type the name of a new connection. Step 4 Specify a serial port of the PC terminal to connect the PC terminal to the disk array, for example, COM1. Step 5 Set the properties of the serial port by referring to Table 5-8, and then click OK. Table 5-8 Setting the properties of a serial port Property Bits per second Data bits Parity check Stop bits Flow control Property Value 115200 8 None 1 None
Step 6 Press Enter. If the connection is successful, a dialog box is displayed, as shown in Figure 5-9.
Figure 5-9 Successful connection interface
Step 7 In the successful connection interface, type the user name and password. Then the successful login success dialog box is displayed, as shown in Figure 5-10.
CAUTION
The initial name and password of the administrator is admin and 123456, respectively. To ensure the system security, you need to change the password after the initial login.
Figure 5-10 Successful login dialog box
5-34
Issue 03 (2010-08-31)
Step 8 Run the following command to set the IP address of the Ethernet port managed by controller A: OceanStor:admin> chgctrlip -c a -a new IP address of controller A -s subnet mask -g gateway For example, to change the IP address of the Ethernet port that is managed by controller A to 10.71.15.20, run the following command: OceanStor:admin> chgctrlip -c a -a 10.71.15.20 -s 255.255.255.0 -g 10.71.15.1 When the system displays the following prompt, type y:
OceanStor: admin> chgctrlip -c a -a 10.71.15.20 -s 255.255.255.0 This operation will change your controller's IP configuration. if you want to ch ange the IP of the controller you logged in, you will log out after you set the new IP. However, if you change the IP of the peer controller, you needn't log out. Do you want to continue? y or n: y
Step 9 Run the following command to check whether the IP address is correct: OceanStor:admin> showctrlip -c a
Controller IP Address A 10.71.15.20 00:18:82:e2:00:fb Subnet Mask 255.255.255.0 Gateway 10.71.15.1 MAC Address
Step 10 Run the following command to set the IP address of the Ethernet port managed by controller B: OceanStor:admin> chgctrlip -c b -a new IP address of controller A -s subnet mask -g gateway For example, to change the IP address of the Ethernet port that is managed by controller B to 10.71.15.21, run the following command: OceanStor:admin> chgctrlip -c b -a 10.71.15.21 -s 255.255.255.0 -g 10.71.15.1 When the system displays the following prompt, type y:
This operation will change your controller's IP configuration. if you want to ch ange the IP of the controller you logged in, you will log out after you set the new IP. However, if you change the IP of the peer controller, you needn't log out. Do you want to continue? y or n: y
Step 11 Run the following command to check whether the IP address is correct: OceanStor:admin> showctrlip -c b
IP Address B 10.71.15.21 00:18:82:e2:01:57 Controller Subnet Mask 255.255.255.0 Gateway 10.71.15.1 MAC Address
----End
Postrequisite
During commissioning, you need to configure the monitoring function of the S2600 disk array after you install and configure the M2000 client application. For details, see section "Configuring the Monitoring Function of the S2600 Disk Array". During maintenance, if the monitoring function of the S2600 disk array is configured, you need to reconfigure this function after changing the IP address of the server. For details, see section "How to Configuring the Monitoring Function of the S2600 Disk Array" in the corresponding administrator manual.
6 Managing the M2000 Clients
6
About This Chapter
Context
l
Managing the M2000 Clients
This chapter describes how to manage the M2000 clients. The graphic user interface (GUI) on the M2000 client supports the O&M for the NEs and enables you to monitor the M2000. You must manage the M2000 clients to ensure their normal operation.
The requirements of the M2000 client for operation rights are as follows: The users who are authorized to install, upgrade, and uninstall the M2000 client are Windows users. They belong to the user group Administrators. The users who are responsible for the routine maintenance of the M2000 client must belong to the user group Users and have the read and write rights of the M2000 client installation directory.
6.1 Managing Files and Disks on M2000 Clients This section describes how to manage the file systems and disks on the M2000 clients. 6.2 Monitoring the Login Status of the M2000 Clients This section describes how to monitor the login status of the M2000 clients (including the LMTs which access NEs through the M2000 proxy). When the number of login clients exceeds the preset maximum number of M2000 threads, you must force a user out to establish a new connection. 6.3 Setting the Number of Clients Accessible on a PC This section describes how to edit the configuration file on the M2000 client for setting the number of clients of the same version (excluding the LMTs that gain access to NEs through the M2000 proxy) that can be started on a PC. 6.4 Setting the Time Information on the M2000 Client This section describes how to set the time information on the M2000 client.
Issue 03 (2010-08-31)
6-1
6.1 Managing Files and Disks on M2000 Clients

This section describes how to manage the file systems and disks on the M2000 clients. 6.1.1 Introduction to the M2000 Client File System This introduces the M2000 client file system. 6.1.2 Clearing the Disk Space of an M2000 Client This section describes how to clear the disk space of an M2000 client. Before performing this operation, ensure that the files to be deleted are not required for future operations. Deleting a useful file by mistake may lead to a system operation error.
6.1.1 Introduction to the M2000 Client File System

This introduces the M2000 client file system. The client software runs on the Windows operating system and is based on the JAVA virtual machine. The installation package of the M2000 client software includes the JAVA virtual machine supported by Windows. Required client disk space (only for reference): F = I + T + (S x N), where I refers to the size of the initial version, that is, about 300 MB; T refers to the temporary space for saving patches, which is less than 20 MB; S refers to the size of mediation files, which ranges from 3 MB to 10 MB; N refers to the number of NE versions, which depends on the actual situation. Table 6-1 describes the parameters specified in the equations. Table 6-1 M2000 client software directory Directory client installation path Description Refers to the installation path of the M2000 client software. The default path is C: \iManagerM2000ClientClient. Refers to the path for saving client programs. Refers to the path for saving executable files. Refers to the path for saving NE configuration files. Refers to the path for saving the information that is used for locating problems.
NOTE This path appears only after you run the M2000 diagnosis tool.
M2000 client installation path\client M2000 client installation path\client\bin M2000 client installation path\client \Data M2000 client installation path\client \diagnosis
M2000 client installation path\client \ext_runcfg M2000 client installation path\client\dtd M2000 client installation path\client \IDAPI32
6-2
Refers to the path for saving the configuration files of integrated components. Refers to the path for saving .dtd files. Refers to the path for saving the localWS dynamic link libraries.
Issue 03 (2010-08-31)
Directory M2000 client installation path\client\lib M2000 client installation path\client \localWs M2000 client installation path\client \style M2000 client installation path\client \Templates M2000 client installation path\client\tmp M2000 client installation path\client \tracefile M2000 client installation path\client \update M2000 client installation path\client\cbb M2000 client installation path\client \configuration M2000 client installation path\client \features M2000 client installation path\client \plugins M2000 client installation path\uninstall M2000 client installation path\script M2000 client installation path\client\bin \run
Description Refers to the path for saving the library files. Refers to the path for saving LocalShell that is used to start the 2G LMT. Refers to the path for saving the configuration files of the client. Refers to the path for saving the mapping between administrative regions and their IDs. Refers to the path for saving temporary files during the upgrade. Refers to the path for saving trace files. Refers to the path for saving upgrade files. Refers to the path for saving the CBB files of the M2000 client. Refers to the buffer path of the M2000 client. The path automatically generates when the client is started. Refers to the path for saving the feature configuration file of each subsystem of the M2000 client. Refers to the path for saving the configuration file of each subsystem of the M2000 client as plug-ins. Refers to the path for saving the uninstallation program. Refers to the root path of the iSStar script. Refers to the path for saving the startup parameter configuration files of the client and components.
Issue 03 (2010-08-31)
6-3
Directory M2000 client installation path\cau
Description Refers to the path for saving the Client Auto Upgrade (CAU) client software and the version, document abstract, and group information about the M2000 client.
NOTE
l The CAU client software provides the upgrade
detection mechanism that is based on the document abstract for comparing the document abstract of the server with that of the client. If the document abstracts are not consistent, you need to upgrade the client.
l Based on the group information, the server groups
and packs all the client documents deployed on the server so that the client can download, install, and upgrade these documents. Based on the group information, the client also groups and packs all the client files. Therefore, these files can be compared with those grouped and packed by the server after being downloaded.
M2000 client installation path\jre M2000 client installation path\lib
Refers to the path for saving the Java virtual machine delivered with the M2000 client. Refers to the path for saving the dynamic libraries shared among the M2000 client, remote alarm notification client, script framework client, and data management client. Refers to the path of the remote alarm notification tool. Refers to the path of the trace review tool.
M2000 client installation path\notify M2000 client installation path \TrafficReview
6.1.2 Clearing the Disk Space of an M2000 Client

This section describes how to clear the disk space of an M2000 client. Before performing this operation, ensure that the files to be deleted are not required for future operations. Deleting a useful file by mistake may lead to a system operation error.
Context
CAUTION
You can delete the files when the client is running. Do not delete the files generated on that day. During the routine O&M, back up and clear the following files:
l
Trace logs
6-4

l
Temporary files after the running of the M2000 log collector
Procedure
l Delete the trace logs. Delete the history trace logs saved in the directory M2000 client installation path\client \tracefile. It is recommended that you preserve the trace logs generated in the latest two weeks. l Delete the temporary files generated after the running of the M2000 log collector. Delete the temporary files that are generated after the running of the M2000 log collector and are saved in the directory M2000 client installation path\client\diagnosis. ----End
6.2 Monitoring the Login Status of the M2000 Clients

This section describes how to monitor the login status of the M2000 clients (including the LMTs which access NEs through the M2000 proxy). When the number of login clients exceeds the preset maximum number of M2000 threads, you must force a user out to establish a new connection.
Prerequisite
Before monitoring the M2000 clients, ensure that you are authorized to monitor the users.
Procedure
Step 1 Start the M2000 client and log in to the M2000 server. Step 2 Choose Security > User Session Monitoring. The User Session Monitoring dialog box is displayed. Step 3 Click the User Session Monitoring tab to monitor all the terminals connected to the M2000 system. Pay special attention to information such as login IP address and login time. Step 4 Click Refresh to refresh the session list. This step is optional. Step 5 If you need to force a user to exit, select the user, and then click Force User to Log Out.
NOTE
The user of the selected client is forced out. The users of the other clients do not exit. The current user cannot force itself to exit.
----End
6.3 Setting the Number of Clients Accessible on a PC

This section describes how to edit the configuration file on the M2000 client for setting the number of clients of the same version (excluding the LMTs that gain access to NEs through the M2000 proxy) that can be started on a PC.
Prerequisite
l l
You have logged in to the PC as a user in the user group Users. The M2000 client is running properly.
Context
Ideally, a maximum of 31 M2000 clients of the same version can be started on a PC. The number of clients of the same version connected to a PC depends on the configuration of the PC and that of the server connected to the PC. In the M2000 client installation directory\client\plugins\com.swimap.omc.common\style \productstyle\com.swimap.corba\conf\communicate.xml file, the value of corba_portpool indicates the port range that the client attempts to occupy. The minimum port number is separated from the maximum number by "-". The client tests the port from the minimum number to the maximum number. If all the ports are occupied, the system displays an Error message. You can set the maximum number of clients of the same version started on a PC by modifying the value of corba_portpool.
Procedure
Step 1 Open the communicate.xml file in the M2000 client installation path\client\plugins \com.swimap.omc.common\style\productstyle\com.swimap.corba\conf directory. Step 2 Find the corba_portpool field, and then change the range of the ports as required.
<?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE COMMINIDATA SYSTEM "commini.dtd"> <COMMINIDATA> <AREADESC areaname="communicate"> <DESC descname="communicate"> <PARAS> <PARA name="operation" value="modify"></PARA> <PARA name="corba_portpool" value="30500-30699"/> </PARAS> </DESC> </AREADESC> </COMMINIDATA>
NOTE
l l l
The ports after modification cannot exceed the range from 30500 to 30699. Ensure that the ports in the modified range on the firewall are enabled when you modify the port range. The ports may be used by other applications. Perform the following substeps to check the occupation of the ports. 1. Choose Start > Run. The Run dialog box is displayed. 2. Type cmd. Then, click OK. 3. In the displayed window, run the netstat -an command to check the occupation of the ports.
----End
6.4 Setting the Time Information on the M2000 Client

This section describes how to set the time information on the M2000 client. 6.4.1 Modifying the Date, Time, and Time Zone on the M2000 Client
This section describes how to modify the date, time, and time zone on the M2000 client running the Windows operating system. You can modify the date, time, and time zone on the M2000 client by modifying the date, time, and time zone of the Windows. 6.4.2 Setting the NTP Service on the M2000 Client This section describes how to set the M2000 client as the NTP client. This task enables you to synchronize the client with the NTP server through the NTP service of the Windows operating system.
6.4.1 Modifying the Date, Time, and Time Zone on the M2000 Client
This section describes how to modify the date, time, and time zone on the M2000 client running the Windows operating system. You can modify the date, time, and time zone on the M2000 client by modifying the date, time, and time zone of the Windows.
Prerequisite
The Windows operating system is operational.
Procedure
Step 1 Open the Control Panel. This section takes the Windows XP operating system as an example. Step 2 Double-click Date and Time. Step 3 In the Date and Time Properties dialog box, select the items to be modified. Item Hour Minute Second Operation Set the required hour on the Time tab page. Set the required minute on the Time tab page. Set the required second on the Time tab page.
Time Zone Click the Time Zone tab. On the Time Zone tab page, choose the local time zone from the drop-down list. Step 4 Click Apply. ----End
6.4.2 Setting the NTP Service on the M2000 Client

This section describes how to set the M2000 client as the NTP client. This task enables you to synchronize the client with the NTP server through the NTP service of the Windows operating system.
Issue 03 (2010-08-31)
6-7
Prerequisite
l
You have logged in to the Windows operating system. The Windows operating system is running properly. The M2000 client and the M2000 server communicate normally. The clock source of the server is operational.
l l
Context
When the M2000 client is configured as the NTP client, synchronize the time of the M2000 client with the time of the M2000 server. The configuration procedure is applicable to the Windows 2000 Professional, Windows 2003, Windows 2008, Windows XP Professional or Windows Vista Business operating system.
Procedure
Step 1 Configure the M2000 client as the NTP client. Choose Start > Run. In the displayed Run dialog box, enter regedit to open the Registry Editor window. In the registry, choose HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Services > W32Time > Parameters. Then, change the value of the parameter LocalNTP to 0, which is the default value. If the parameter LocalNTP does not exist, it indicates that the value can be ignored and the registry need not be modified.
NOTE
For the operating systems of Windows 2003 or Windows 2008, In the registry, change the value of Enable under HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Services > W32Time > TimeProviders > NtpServer to 0.
Step 2 Specify the NTP clock source. Choose Start > Run. Type cmd and press Enter. In the displayed window, run the following command: c:\>net time /setsntp:M2000 IP Address of NTP Server
NOTE
1. The result of the net time command is saved in the Windows registry. This setting of the net time takes effect after Windows restarts. 2. To clear the specification, run the net time /setsntp command.
Step 3 Restart the Windows Time service. Choose Start > Run. In the displayed Run dialog box, enter services.msc to open the Services window. Identify the Windows Time service and restart the service. Step 4 Check the NTP server specified by the PC. c:\>net time /querysntp
NOTE
If the host name and IP address of the PC are specified as the host name and IP address of the NTP server by /setsntp, the NTP server time is the local time of the PC.
6-8
Issue 03 (2010-08-31)
Step 5 Perform operations based on operating systems.

l l
If the M2000 client runs on Windows 2000 operating system, perform Step 6. If the M2000 client runs on Windows 2003, Windows 2008, Windows XP or Windows Vista operating system, perform Step 7 through Step 8.
Step 6 Run the following command to check the running status of the SNTP: c:\>w32tm -once -v -test The system displays the host name of the connected NTP server, deviation between the local time and the NTP server time, and time cycle of NTP server roll. Step 7 Run the following command to manually synchronize the time: c:\>w32tm /resync Step 8 Run the following command to check the running status of the SNTP: c:\>w32tm /stripchart /computer:IP address of the M2000 server /dataonly The system displays the following information, including the local time of the client and deviation of the local time from that on the NTP server.
Tracking 10.71.15.98 [10.71.15.98]. The current time is 2009-6-22 10:05:09 (local time). 10:05:09, +04.9881239s 10:05:11, +04.9814570s 10:05:13, +04.9740897s 10:05:15, +04.9589559s 10:05:17, +04.9449507s ...
In the system output, the first column displays the local time of the client, and the second column displays the deviation between the local time and the server time. + indicates that the client time is earlier than the server time. - indicates that the client time is later than the server time. You can press Ctrl+C to exit the browse window. ----End
Issue 03 (2010-08-31)
6-9
7 Managing the M2000 Users (HA)
Managing the M2000 Users (HA)
About This Chapter

This chapter describes the four types of users involved in the operation of the M2000 system: Solaris user, Sybase user, network management user, and NE user. In addition, it describes the management and monitoring operations related to the types of users and M2000 user groups. 7.1 Types of M2000 Users This section describes the four types of users involved in the operation of the M2000 system: Solaris user, Sybase user, network manager user, and NE user. In addition, it describes the mapping between the network manager user and NE user and the principle for assigning their rights. 7.2 Managing Solaris Users (HA) This section describes how to manage the Solaris users. The four types of Solaris users involved in running the M2000 server are: root, dbuser, omcuser, and ftpuser. In addition, it describes how to create a user, remove a user, and modify a password. 7.3 Managing Sybase Users (HA) This chapter describes how to manage the Sybase user that is required for the operation of the M2000. This chapter also describes how to change the password of the Sybase user. 7.4 Managing OM Users OM users operate and maintain the entire network or specified NEs through the M2000. The M2000 provides the user management function. By using this function, you can manage user information and user rights. You can also monitor user sessions and operations. This helps to prevent unauthorized operations and ensure system security.
Issue 03 (2010-08-31)
7-1
7.1 Types of M2000 Users

This section describes the four types of users involved in the operation of the M2000 system: Solaris user, Sybase user, network manager user, and NE user. In addition, it describes the mapping between the network manager user and NE user and the principle for assigning their rights. 7.1.1 Introduction to Solaris Users This introduces the Solaris users involved in the operation of the M2000 server. 7.1.2 Introduction to Sybase Users This introduces the Sybase user accounts used by the M2000 and the mapping authorities. 7.1.3 NE Users NE users refer to the users accounts that can log in to and operate and maintain NEs through the LMT or WEB LCT. To use the LMT or WEB LCT to operate and maintain NEs (for example, in the case that NEs are not connected to or are disconnected from the M2000), you need to operate and maintain NEs as NE users. NE users can also perform operations such as troubleshooting at the near ends of NEs. 7.1.4 Principles of NM User Authorization This section describes various privileges of the M2000 NM users and the principles for user authorization. The M2000 assigns privileges to user groups. The privileges assigned to a group are passed on to individual users based on the binding between the user group and the users in the user group. The privileges can also be assigned to users directly. 7.1.5 Principles of NE User Authorization This section describes the principles of NE user authorization. The M2000 supports the authorization of operation privileges provided to NE user accounts.
7.1.1 Introduction to Solaris Users

This introduces the Solaris users involved in the operation of the M2000 server. To access the M2000 server, you must have a user account of a Solaris operating system. In addition to the default account of the Solaris operating system, that is, user root, you must have the three manually created user accounts: dbuser, omcuser, and ftpuser. You must also have one manually created user group: omcsysm. The default password and user name of each user account are the same.
l l l l
The default password of user root is root. The default password of user dbuser is dbuser. The default password of user omcuser is omcuser. The default password of user ftpuser is ftpuser.
Table 7-1 describes the Solaris user accounts.
7-2
Issue 03 (2010-08-31)
Table 7-1 Solaris user accounts Account Name Usage Authority Group Shell Resoluti on Program Directory
root
User root is the default user account of the system. User root is authorized to control all resources, create other user accounts, assign authorities to other users, and perform all system operations. User dbuser is the administrator of the database software. User dbuser is responsible for the O&M of the database software. Before installing the Sybase, you must manually create user dbuser.
User root owns the highest authority of the system. User root is authorized to install and uninstall M2000 server applications and to start and stop M2000 services.
Other, /bin/bash bin, sys, adm, uucp, mail, tty, lp, nuucp, daemon, and user.root
dbuser
User dbuser is authorized to perform all operations on the database. For example, user dbuser is authorized to use isql to interact with the database.
Staff and omcsys m
/bin/bash
/opt/sybase
Issue 03 (2010-08-31)
7-3
Account Name
Usage
Authority
Group
Shell Resoluti on Program /bin/bash
Directory
omcuser
User omcuser is the operator of the M2000. User omcuser is responsible for the O&M of the M2000 system, such as system status inquiry, system backup, and system restoration. Before installing the M2000 applications, you must create user omcuser.
User omcuser is authorized to access the database and perform the O&M operations. User omcuser is not allowed to install or uninstall M2000 server applications.
Staff (primary group), sys, root, and omcsys m (seconda ry group)
/export/home/ omc
ftpuser
User ftpuser is used by the M2000 applications to perform software management and file transmission. Before installing the M2000 applications, you must create user ftpuser.
User ftpuser is authorized to perform software management and file transmissions for NEs.
omcsys m
/bin/bash
/export/home/ sysm
7.1.2 Introduction to Sybase Users

This introduces the Sybase user accounts used by the M2000 and the mapping authorities. To operate the database on the M2000 server, you must use a Sybase user account. Only Sybase users can operate the Sybase database. After the Sybase is installed, the default user account of the Sybase is sa, which has the highest authority. In the M2000 system, sa is the only database user. The default password of user sa is emsems.
7.1.3 NE Users
NE users refer to the users accounts that can log in to and operate and maintain NEs through the LMT or WEB LCT. To use the LMT or WEB LCT to operate and maintain NEs (for example, in the case that NEs are not connected to or are disconnected from the M2000), you need to
operate and maintain NEs as NE users. NE users can also perform operations such as troubleshooting at the near ends of NEs.
Types of NE Users
NE users consist of local NE users and non-local NE users.
l
Local NE users refer to the users whose account, password, and authority are managed by NEs. The creation and modification of a local NE user are performed on the LMT. NEs provide several default local users.
CAUTION
NodeBs have only default local users because they do not have the BAM and cannot create any local user.
l
The account, password, and authority of a non-local NE user are managed by the M2000. The creation and modification of a non-local NE user are performed on the M2000.
Management of Mode 1 NE Users

Mode 1 NEs of centralized user management support local and non-local NE users. If an OM user is granted with the MML authority of a mode 1 NE, the OM user becomes a non-local user of this NE. You can log in to the M2000 as a non-local NE user to operate and maintain the mode 1 NEs. For details about mode 1 NEs, see NEs Corresponding to Different Centralized User Management Modes. The M2000 manages non-local users, which consist of OM user accounts and NE user accounts. Thus, non-local NE users have higher priority than local NE users. You can set whether to enable NE local users to log in to and manage NEs on the M2000.
Management of Mode 2 NE Users

Mode 2 NEs of centralized user management support only local NE users. For the list of mode 2 NEs, see NE Types. To perform centralized management on mode 2 NEs, you can create an NE User account for each local NE user (with the same user name and password) in the NE User Management window on the M2000 and correlate the accounts to the corresponding OM users. You can log in to the M2000 as a non-local OM user that is correlated to a local NE user to operate and maintain the mode 2 NEs.
NOTE
The information about the user account on the M2000 and that on the NE is independent from each other, and thus they cannot be automatically synchronized. You need to manually synchronize the information about the NE user on the M2000 according to the information about the local NE user.
Management of Optical Transmission NE Users

Optical transmission NEs support only local NE users. For details about optical transmission NEs, see NE Types. In the NE User Management window on M2000, you can create NE users for the optical transmission NEs. In the Main Topology window on the M2000, you can use a created or default
NE user as a parameter for creating an optical transmission NE and then log in to the NE to operate and maintain it.
7.1.4 Principles of NM User Authorization

This section describes various privileges of the M2000 NM users and the principles for user authorization. The M2000 assigns privileges to user groups. The privileges assigned to a group are passed on to individual users based on the binding between the user group and the users in the user group. The privileges can also be assigned to users directly. A user group is a group of users who share the same privileges. The M2000 has four default user groups: Administrators, Operators, Guests and SMManagers. Table 7-2 describes the M2000 user privileges. Table 7-2 Privileges of M2000 users Privileges Operation period Description Period during which M2000 users can log in to and operate the M2000 or NEs. If the current time is not within the period, M2000 users cannot log in. Validity of a user account Check the validity of a user account. Generally, the status of a user account is valid. If the status of a user account is invalid, the user cannot log in to or operate the M2000. If the number of login failures of a user account during the specified period reaches the preset value, the system locks the user account. The user, whose account is invalid, cannot log in to or operate the M2000. Binding IP address The M2000 does not restrict the IP address of the client using which users log in. After a M2000 user is bound to an IP address, the IP address of the client using which the user logs in must exist in the list of bound IP addresses. Setting the list of bound IP addresses when creating a user account Changing the list of bound IP addresses by modifying the attributes of a user account Related Operations Setting the operation period when creating a user account Changing the operation period by modifying the attributes of a user account If a user account is locked for a period greater than the time set by the system, the system automatically unlocks the user account. The system also allows you to manually unlock a user account. Modifying user validity by modifying the attributes of a user account
Locking status
7-6
Issue 03 (2010-08-31)
Privileges M2000 operation rights
Description A user has the authority to perform relevant operations on the M2000. After the privileges of users are bound, private privileges for operating the M2000 can be allocated to users directly. The public privileges for operating the M2000 can be allocated first to user groups and then to users based on the binding relations between the user groups and the users. Private privileges refer to the privileges enjoyed by private users. Public privileges are the privileges enjoyed by all the users in a user group. With regard to convenience and efficiency, the recommended privileges are public privileges.
Related Operations Private privileges indicate that the privileges for operating the M2000 are allocated to users after their privileges are bound. Public privileges indicate that the privileges for operating the M2000 can be allocated first to user groups and then to users based on the binding relations between user groups and users.
7.1.5 Principles of NE User Authorization

This section describes the principles of NE user authorization. The M2000 supports the authorization of operation privileges provided to NE user accounts. Each type of NEs provide certain default MML command group. In addition, you can customize new command groups. The principles of NE user authorization are as follows:
l
Prefer to use the default command groups provided by NEs. If you have to customize command groups, customize them as few as possible. Use the principles of NE user authorization for assigning the privileges that are commonly used by NE users and certain NE types. For the privileges that are applicable for certain NEs and cannot be assigned by using the principles of NE user authorization, you must assign them by directly setting users and the command groups of these NEs.
NOTE
l l
Superuser admin can run NE MML commands on the M2000 even without authorization. For details on the authority to manage an NE, refer to the M2000 Online Help.
7.2 Managing Solaris Users (HA)

This section describes how to manage the Solaris users. The four types of Solaris users involved in running the M2000 server are: root, dbuser, omcuser, and ftpuser. In addition, it describes how to create a user, remove a user, and modify a password.
Issue 03 (2010-08-31)
7-7
7.2.1 Introduction to Solaris Users This introduces the Solaris users involved in the operation of the M2000 server. 7.2.2 Changing the Password of User root This section describes how to change the password of user root. The password of user root on the two nodes must be consistent. Thus, you must change the password of user root on the two nodes to ensure the password consistency. 7.2.3 Changing the Password of User dbuser This section describes how to change the password of user dbuser when you log in to the system as user root. The password of user dbuser on the two nodes must be consistent. Thus, you must change the password of user dbuser on the two nodes to ensure the password consistency. 7.2.4 Changing the Password of User omcuser This section describes how to change the password of user omcuser when you log in to the system as user root. The password of user omcuser on the two nodes must be consistent. Thus, you must change the password of user omcuser on the two nodes to ensure the password consistency. 7.2.5 Changing the Password of the User ftpuser (HA) This section describes how to change the password of user ftpuser of the Sybase. 7.2.6 Creating a Solaris User This section describes how to create a Solaris user. The Solaris user can operate and maintain the Solaris system. 7.2.7 Deleting a Solaris User This section describes how to delete a Solaris user. You can manually delete the Solaris user that is not required.
7.2.1 Introduction to Solaris Users

This introduces the Solaris users involved in the operation of the M2000 server. To access the M2000 server, you must have a user account of a Solaris operating system. In addition to the default account of the Solaris operating system, that is, user root, you must have the three manually created user accounts: dbuser, omcuser, and ftpuser. You must also have one manually created user group: omcsysm. The default password and user name of each user account are the same.
l l l l
The default password of user root is root. The default password of user dbuser is dbuser. The default password of user omcuser is omcuser. The default password of user ftpuser is ftpuser.
Table 7-3 describes the Solaris user accounts.
7-8
Issue 03 (2010-08-31)
Table 7-3 Solaris user accounts Account Name Usage Authority Group Shell Resoluti on Program Directory
root
User root is the default user account of the system. User root is authorized to control all resources, create other user accounts, assign authorities to other users, and perform all system operations. User dbuser is the administrator of the database software. User dbuser is responsible for the O&M of the database software. Before installing the Sybase, you must manually create user dbuser.
User root owns the highest authority of the system. User root is authorized to install and uninstall M2000 server applications and to start and stop M2000 services.
Other, /bin/bash bin, sys, adm, uucp, mail, tty, lp, nuucp, daemon, and user.root
dbuser
User dbuser is authorized to perform all operations on the database. For example, user dbuser is authorized to use isql to interact with the database.
Staff and omcsys m
/bin/bash
/opt/sybase
Issue 03 (2010-08-31)
7-9
Account Name
Usage
Authority
Group
Shell Resoluti on Program /bin/bash
Directory
omcuser
User omcuser is the operator of the M2000. User omcuser is responsible for the O&M of the M2000 system, such as system status inquiry, system backup, and system restoration. Before installing the M2000 applications, you must create user omcuser.
User omcuser is authorized to access the database and perform the O&M operations. User omcuser is not allowed to install or uninstall M2000 server applications.
Staff (primary group), sys, root, and omcsys m (seconda ry group)
/export/home/ omc
ftpuser
User ftpuser is used by the M2000 applications to perform software management and file transmission. Before installing the M2000 applications, you must create user ftpuser.
User ftpuser is authorized to perform software management and file transmissions for NEs.
omcsys m
/bin/bash
/export/home/ sysm
7.2.2 Changing the Password of User root

This section describes how to change the password of user root. The password of user root on the two nodes must be consistent. Thus, you must change the password of user root on the two nodes to ensure the password consistency.
Prerequisite
l l
The old password of user root is available. The new password of user root is available.
Procedure
Step 1 Log in as user root through SSH mode, and then enter the old password of user root.
Step 2 Change the password. # passwd root New password:new password Re-enter new password:new password
passwd: password successfully changed for root
----End
7.2.3 Changing the Password of User dbuser

This section describes how to change the password of user dbuser when you log in to the system as user root. The password of user dbuser on the two nodes must be consistent. Thus, you must change the password of user dbuser on the two nodes to ensure the password consistency.
Prerequisite
l l
The new password for dbuser is available. Log in to the M2000 server as user root through SSH mode.
Procedure
Step 1 Run the following command to change the password: # passwd dbuser New password:new password Re-enter new password:new password
passwd: password successfully changed for dbuser
----End
7.2.4 Changing the Password of User omcuser

This section describes how to change the password of user omcuser when you log in to the system as user root. The password of user omcuser on the two nodes must be consistent. Thus, you must change the password of user omcuser on the two nodes to ensure the password consistency.
Prerequisite
l l
The new password for omcuser is available. Log in to the M2000 server as user root through SSH mode.
Context
NOTE
The provided password must meet the policy of minimum complexity. The password comprises of at least 6 letters or digits, among which one digit or special character is included.
Issue 03 (2010-08-31)
7-11
Procedure
Step 1 Run the following command to change the password: # passwd omcuser New password:new password Re-enter new password:new password
passwd: password successfully changed for omcuser
----End
7.2.5 Changing the Password of the User ftpuser (HA)

This section describes how to change the password of user ftpuser of the Sybase.
Prerequisite
l l
The new password of user ftpuser is available. Log in to both servers as user root through SSH mode.
Context
CAUTION
l
After the installation and commissioning of the M2000 HA system are complete, osssvr-1 acts as the active node and provides services, and osssvr-2 acts as the standby node. You can run the modify script to change the password of user ftpuser only when osssvr-1 is the active node and osssvr-2 is the standby node. If the server does not meet the requirement of the active/standby relation, you need to manually adjust the relation. The special characters '"$ cannot be contained in the password of user ftpuser. To improve the password security, you are advised to use the following policies to set the password:
l l l l l l
The password length ranges from 8 to 30 characters. At least one uppercase is contained in the password. At least one lowercase is contained in the password. At least one digit is contained in the password. At least one special character is contained in the password. No user name is contained in the password.
Procedure
Step 1 On either node, run the following command to determine the active and standby nodes: # scstat -D In the system output, the node corresponding to the Primary column is the active node and the node corresponding to the Secondary column is the standby node.
This takes osssvr-1 as the active node and osssvr-2 as the standby node as an example.
NOTE
You can run the modify script to change the password of user ftpuser only when osssvr-1 is the active node and osssvr-2 is the standby node. If the server does not meet the requirement of the active/standby relation, you need to manually adjust the relation. For details, see 3.2.2 Manually Switching Over Active and Standby Nodes (HA).
Step 2 If the M2000 services are running, run the following command on the active node to stop the M2000 services: # scswitch -n -j ossapp_rs Step 3 Run the following command on both nodes to check whether there is any output. If no output exists, you can infer that the M2000 daemon process is stopped. # . /opt/OMC/svc_profile.sh # daem_ps Step 4 If the daemon process continues running, run the following command to stop it: # kill_daem Step 5 Check whether the Sybase services are started. For details, see 16.2.1 How Do I Check Whether the Sybase Is Started. If the Sybase services are not started, start them first. For details, see 16.2.2 How to Start the Sybase (HA, Sun). If the Sybase services are started, perform Step 6. Step 6 On the active node, run the modify script to change the password of user ftpuser. 1. Run the modify script. The default installation directory of the M2000 server software is /opt/OMC. # . /opt/OMC/svc_profile.sh # cd /opt/OMC/tools/config # ./modify.sh 2. 3. Choose 4--Password of ftpuser. Based on the system prompt, enter the new password of user ftpuser twice.
-----------------------------------------------------------------Note: -- Enter key p/P to return pre-step -- Enter key q/Q to exit this tools -----------------------------------------------------------------Please input the new ftpuser password: Please Re-enter the password:
NOTE
l l
Enter p or P. The system displays the function menu of the modify script, prompting you to perform operations such as changing the IP address or user password. Enter q or Q to exit the modify script.
4.
When the system displays the following information, enter Y to apply the change.
Are you sure to continue? Y--Yes. Q--Quit.
Issue 03 (2010-08-31)
7-13

R--Re-input P--Return pre-step Please make a choice[Y/Q/R/P]: Y
NOTE
l l l l
Enter Q to exit the script without performing any operations. Enter R to return to Step 6.3. You can reconfigure the relevant parameters. Enter P. The system displays the function menu of the modify script, prompting you to perform operations such as changing the IP address or user password. You need to wait for about one minute if you run the modify script to change the password of user ftpuser.
5.
When the system displays the following information, you can infer that the change is successful.
If the system output contains failed, you can infer that the change fails. Contact Huawei technical support engineers for assistance. 6. When the system displays the function menu again, enter q to exit.
Step 7 Check whether the Sybase services are started. For details, see 16.2.1 How Do I Check Whether the Sybase Is Started. If the Sybase services are not started, start them first. For details, see 16.2.2 How to Start the Sybase (HA, Sun). If the Sybase services are started, perform Step 8. Step 8 On the active node, run the following command to start the M2000 services. # scswitch -e -j ossapp_rs Step 9 On the standby node, run the following command to check whether there is any output: # . /opt/OMC/svc_profile.sh # daem_ps
l l
----End
7.2.6 Creating a Solaris User

This section describes how to create a Solaris user. The Solaris user can operate and maintain the Solaris system.
Prerequisite
Keep the user account and password ready for the new user.
Context
Before the installation of the Sybase and the M2000 server software, create three Solaris user accounts: dbuser, omcuser, and ftpuser. For details, see the software installation manual related to each server type. You can also create other user accounts if required. After a user account is created, the details about this user account are saved in system files of the Solaris.
Procedure
Step 1 Log in to the server as user root through SSH mode. Step 2 Run the following command to create a new user account: # useradd Option new user account For instance, create a user account named omc1. User omc1 belongs to the staff group. The main directory /home1 is automatically created. The template files ensure a unified operating environment for all the users. The template files are located in the /etc/skel directory with user ID 123. This user account is in Bourne shell. # useradd -d /home1 -g staff -m -k /etc/skel -u 123 -s /bin/bash omc1
NOTE
For details of the useradd command, refer to M2000 Command Reference.
Step 3 Run the following command to set the password for the new user: # passwd omc1 New password:new password Re-enter new password:new password
passwd: password successfully changed for omc1
----End
7.2.7 Deleting a Solaris User

This section describes how to delete a Solaris user. You can manually delete the Solaris user that is not required.
Prerequisite
The account of the user to be deleted is available.
Procedure
Step 1 Log in to the M2000 server as user root through SSH mode. Step 2 Run the following command to delete a user account and the main directory of the account: # userdel -r user account For details of the userdel command, refer to M2000 Command Reference.

NOTE
Do not delete the users required for the OM of the M2000, such as ftpuser, dbuser, and omcuser.
----End
7.3 Managing Sybase Users (HA)

This chapter describes how to manage the Sybase user that is required for the operation of the M2000. This chapter also describes how to change the password of the Sybase user. 7.3.1 Introduction to Sybase Users This introduces the Sybase user accounts used by the M2000 and the mapping authorities. 7.3.2 Changing the Password of the User sa (HA) This section describes how to change the password of user sa.
7.3.1 Introduction to Sybase Users

This introduces the Sybase user accounts used by the M2000 and the mapping authorities. To operate the database on the M2000 server, you must use a Sybase user account. Only Sybase users can operate the Sybase database. After the Sybase is installed, the default user account of the Sybase is sa, which has the highest authority. In the M2000 system, sa is the only database user. The default password of user sa is emsems.
7.3.2 Changing the Password of the User sa (HA)

This section describes how to change the password of user sa.
Prerequisite
l l
The new password of user sa is available. Log in to both servers as user root through SSH mode.
7-16
Issue 03 (2010-08-31)
Context
CAUTION
l
After the installation and commissioning of the M2000 HA system are complete, osssvr-1 acts as the active node and provides services, and osssvr-2 acts as the standby node. You can run the modify script to change the password of user sa only when osssvr-1 is the active node and osssvr-2 is the standby node. If the server does not meet the requirement of the active/standby relation, you need to manually adjust the relation. To improve the password security, you are advised to use the following policies to set the password:
l l
The valid password ranges from 8 to 30 characters. The special characters '"$ cannot be contained in the password. Instead, the password can contain only 0~9, a~z, A~Z, and special characters ~!@#%^&*()_-+=|\/ <>,.;:[]{}.
Procedure
Step 1 On either node, run the following command to determine the active and standby nodes: # scstat -D In the system output, the node corresponding to the Primary column is the active node and the node corresponding to the Secondary column is the standby node. This takes osssvr-1 as the active node and osssvr-2 as the standby node as an example.
NOTE
You can run the modify script to change the password of user sa only when osssvr-1 is the active node and osssvr-2 is the standby node. If the server does not meet the requirement of the active/standby relation, you need to manually adjust the relation. For details, see 3.2.2 Manually Switching Over Active and Standby Nodes (HA).
Step 2 If the M2000 services are running, run the following command on the active node to stop the M2000 services: # scswitch -n -j ossapp_rs Step 3 Run the following command on both nodes to check whether there is any output. If no output exists, you can infer that the M2000 daemon process is stopped. # . /opt/OMC/svc_profile.sh # daem_ps Step 4 If the daemon process continues running, run the following command to stop it: # kill_daem Step 5 Check whether the Sybase services are started. For details, see 16.2.1 How Do I Check Whether the Sybase Is Started. If the Sybase services are not started, start them first. For details, see 16.2.2 How to Start the Sybase (HA, Sun).
If the Sybase services are started, perform Step 6. Step 6 On the active node, run the modify script to change the password of user sa. 1. Run the modify script. The default installation directory of the M2000 server software is /opt/OMC. # . /opt/OMC/svc_profile.sh # cd /opt/OMC/tools/config # ./modify.sh 2. 3. Choose 3--Database password. Based on the system prompt, enter the previous and new passwords of user sa.
-----------------------------------------------------------------Note: -- Enter key p/P to return pre-step -- Enter key q/Q to exit this tools -----------------------------------------------------------------Please input the old database superuser's password: Please input the new database superuser's password: Please Re-enter the password:
NOTE
l l l l
Enter p or P. The system displays the function menu of the modify script, prompting you to perform operations such as changing the IP address or user password. Enter q or Q to exit the modify script. Press Enter. The default values in the system output are used. You need to enter the new password of user sa twice.
4.
When the system displays the following information, enter Y to apply the change.
Are you sure to continue? Y--Yes. Q--Quit. R--Re-input P--Return pre-step Please make a choice[Y/Q/R/P]: Y
NOTE
l l l l
Enter Q to exit the script without performing any operations. Enter R to return to Step 6.3. You can reconfigure the relevant parameters. Enter P. The system displays the function menu of the modify script, prompting you to perform operations such as changing the IP address or user password. You need to wait for about 12 minutes if you run the modify script to change the password of user sa.
5.
When the system displays the following information, you can infer that the change is successful.
If the system output contains failed, you can infer that the change fails. Contact Huawei technical support engineers for assistance. 6. When the function menu is displayed again, enter q to exit. Step 7 On the active node, run the following command to start the M2000 services. # scswitch -e -j ossapp_rs
Step 8 On the standby node, run the following command to check whether there is any output: # . /opt/OMC/svc_profile.sh # daem_ps
l l
----End
7.4 Managing OM Users

OM users operate and maintain the entire network or specified NEs through the M2000. The M2000 provides the user management function. By using this function, you can manage user information and user rights. You can also monitor user sessions and operations. This helps to prevent unauthorized operations and ensure system security. Managing OM users, see M2000 User Management User Guide.
Issue 03 (2010-08-31)
7-19
8 Managing OSS System (HA)
8
About This Chapter
Managing OSS System (HA)
The M2000 provides the OSS management function. By using this function, you can viewing NE partitioning, managing the M2000 license, monitoring the M2000 server, integrated task management, check OMC status, collecting NM log files. 8.1 Monitoring the M2000 Server (HA) You can monitor the status (including the status of the service, process, hard disk and database) and the component information of the M2000 server as well as logs of the operations performed on the system monitor client. 8.2 Querying the System Logs of the M2000 This section introduces the M2000 system log. System logs record the operation of the M2000 system. System logs also record the files and data tables of various types of information, which can be queried by the M2000 administrator. 8.3 Collecting NM Log Files When the M2000 system fails, you can run the diagnostic tool to collect all the related diagnostic information from the M2000 Server and Client through the FTP protocol. When the M2000 client or server cannot run properly, you can collect all the operational information from the M2000 client or server to locate faults. 8.4 Querying NE Subareas This section describes how to query NE subareas. An NE subarea refers to the M2000 server that manages the NE. If the M2000 server adopts the SUN SLS solution or the ATAE cluster system solution, NEs can be managed by different servers (subareas). On the M2000 client, you can query different NE subareas. 8.5 Managing the M2000 License M2000 licenses can restrict the number of manageable devices, and the availability duration of the M2000. You need to manage the licenses periodically. 8.6 Check OMC status OMC check is used to check the status of the M2000. This check also exports check reports in .html format. The OMC check enables you to find the hidden problems of devices. Thus, severe accidents are avoided and proper operation of current devices is ensured. 8.7 Integrated Task Management
The M2000 provides the function of integrated management of scheduled tasks. Thus, you can browse information such as the task status and the progress. You can also create, modify, and delete user-scheduled tasks. In addition, you can suspend, restore, cancel scheduled tasks, and save task result files to the client. 8.8 Reference of the OSS Management GUI This part describes the OSS management interfaces and related information such as the parameters used in the OSS management. This helps you understand the functions of OSS management easily.
8-2
Issue 03 (2010-08-31)
8.1 Monitoring the M2000 Server (HA)

You can monitor the status (including the status of the service, process, hard disk and database) and the component information of the M2000 server as well as logs of the operations performed on the system monitor client. Choose Monitor > System Monitor > Monitor Browser. The System Monitor Browser window is displayed. The system monitor browser consists of the following items:
l
Service Monitor: Monitors information about services, such as status and start time. Process Monitor: Monitors information about processes, such as number of used handles, CPU usage, memory usage, number of database connections, and number of threads.
Hard Disk Monitor: Monitors information about the disks in the system, such as total capacity, used space, free space, usage, and status.
Database Monitor: Monitors information about the databases in the system, such as status, space, usage, and log space.
Server Monitor: Monitors information about the services, such as status, operating system, memory capacity, CPU usage, and memory usage.
Component Information: Provides information about server components, such as name, version, and description.
8.1.1 Refreshing the Monitoring Information To know the latest running status of the M2000 server, you need to refresh the monitoring information. The M2000 server also periodically refreshes the monitoring information according to the specified monitoring interval. 8.1.2 Checking the CPU and Memory Usage Information About the M2000 Server (HA) This section describes how to check the CPU usage, memory capacity, and free memory space. When the CPU status or memory status of the server is abnormal, you need to locate faults and log in to the server to rectify the faults in time. The client can monitor the active node and standby node simultaneously. 8.1.3 Checking the Disk Usage Information About the M2000 Server Through the M2000 Client (HA) This section describes how to check the disk usage information about the M2000 server through the system monitor browser of the M2000 client. The client can monitor the active node and standby node simultaneously. 8.1.4 Checking the Database Usage Information About the M2000 Server Through the M2000 Client This section describes how to check the database status through the M2000 client to know the usage of the databases. 8.1.5 Checking the M2000 Services
This section describes how to check the M2000 services. When the M2000 services are not running normally, you need to locate faults and log in to the server to rectify the faults in time. 8.1.6 Checking the Status of the M2000 Processes This section describes how to check the status of the M2000 processes. When the M2000 processes are not running normally, you need to locate faults and log in to the server to rectify the faults in time. 8.1.7 Viewing the Information about M2000 Server Components This function enables you to view the information of the components installed on the M2000 server that you log in to. 8.1.8 Saving the Monitoring Information For the convenience of future analysis of the information that is monitored at certain time, you can save the required monitoring information to the server. 8.1.9 Setting Alarm Thresholds for the M2000 This section describes how to set the alarm thresholds for the M2000. On the M2000 client, you can set the alarm thresholds to monitor the server status. The monitoring of system status consists of server monitoring, disk monitoring, databases monitoring, and service monitoring. if the value of a parameter exceeds the threshold, the system generates the corresponding alarm.
8.1.1 Refreshing the Monitoring Information

To know the latest running status of the M2000 server, you need to refresh the monitoring information. The M2000 server also periodically refreshes the monitoring information according to the specified monitoring interval.
Context
l
When you refresh the current tab page, only the information on this tab page is refreshed. The information on other tab pages is not refreshed. When you switch tab pages, the information on these tab pages are refreshed immediately. Therefore, when you switch tab pages, the information is refreshed at the same time.
Procedure
Step 1 Choose Monitor > System Monitor > Browser. Step 2 In the System Monitor Browser window, click the tab of the monitoring information to be refreshed. Step 3 click Refresh. ----End
8.1.2 Checking the CPU and Memory Usage Information About the M2000 Server (HA)
This section describes how to check the CPU usage, memory capacity, and free memory space. When the CPU status or memory status of the server is abnormal, you need to locate faults and log in to the server to rectify the faults in time. The client can monitor the active node and standby node simultaneously.
Prerequisite
l l
You have logged in to the M2000 client. You have the relevant operation rights.
Procedure
Step 1 Choose Monitor > System Monitor > Monitor Browser. The System Monitor Browser window is displayed. Step 2 Click the Server Monitor tab to check the performance of the M2000 server. See Figure 8-1. Figure 8-1 Server Monitor tab page
NOTE
In the CPU Usage (%) column and the Memory Usage (%) column, the green icon indicates that the CPU usage or memory usage of the corresponding server is normal; the red icon indicates that the CPU usage or memory usage of the corresponding server is abnormal. In the case that you have set the performance monitoring threshold for an item, the icon corresponding to the item changes from green to red when the value of the item reaches the threshold.
Step 3 (Optional) Click Save AS to save the monitoring data as a file. You can save the monitoring data in one of the following formats: .txt, .html, .xml, and .csv. ----End
8.1.3 Checking the Disk Usage Information About the M2000 Server Through the M2000 Client (HA)
This section describes how to check the disk usage information about the M2000 server through the system monitor browser of the M2000 client. The client can monitor the active node and standby node simultaneously.
Prerequisite
l l
You have logged in to the M2000 client. You are authorized with the relevant operation rights.
Context
Checking the disk usage information about the M2000 server requires only a few system resources and does not affect system operation.
Procedure
Step 1 Choose Monitor > System Monitor > Monitor Browser. The System Monitor Browser window is displayed. Step 2 Click the Hard Disk Monitor tab to check disk usage information about the M2000 server. See Figure 8-2. Figure 8-2 Hard Disk Monitor tab page
NOTE
In the Status column, the green icon indicates that the usage of the corresponding disk is normal; the red icon indicates that the usage of the corresponding disk is abnormal. If the usage of a disk exceeds the preset threshold, the icon in this column changes from green to red.
8-6
Issue 03 (2010-08-31)
8.1.4 Checking the Database Usage Information About the M2000 Server Through the M2000 Client
This section describes how to check the database status through the M2000 client to know the usage of the databases.
Prerequisite
l l
Context
This operation requires only a few system resources and does not affect system operation.
Procedure
Step 1 Choose Monitor > System Monitor > Monitor Browser. The System Monitor Browser window is displayed. Step 2 Click the Database Monitor tab to check the database status of the M2000 server. See Figure 8-3. Figure 8-3 Database Monitor tab page
NOTE
In the Status column, the green icon indicates that the usage of the corresponding database is normal; the red icon indicates that the usage of the corresponding database is abnormal. If the usage of a database exceeds the preset threshold, the icon in this column changes from green to red.
8.1.5 Checking the M2000 Services

This section describes how to check the M2000 services. When the M2000 services are not running normally, you need to locate faults and log in to the server to rectify the faults in time.
Prerequisite
l l
Context
Checking the M2000 services on the M2000 client requires only a few system resources and does not affect system performance.
Procedure
Step 1 Choose Monitor > System Monitor > Monitor Browser. The System Monitor Browser window is displayed. Step 2 Click the Service Monitor tab to check the M2000 services. See Figure 8-4. Figure 8-4 Service Monitor tab page
NOTE
In the Status column, the green icon indicates that the corresponding process is normal; the red icon indicates the corresponding process is abnormal.
8.1.6 Checking the Status of the M2000 Processes

This section describes how to check the status of the M2000 processes. When the M2000 processes are not running normally, you need to locate faults and log in to the server to rectify the faults in time.
Prerequisite
l l
Context
Checking the states of the M2000 processes on the M2000 client requires only a few system resources and does not affect system performance.
Procedure
Step 1 Choose Monitor > System Monitor > Monitor Browser. The System Monitor Browser window is displayed. Step 2 Click the Process Monitor tab to check the monitoring data of the processes running on the M2000 server. See Figure 8-5. Figure 8-5 Process Monitor tab page
Issue 03 (2010-08-31)
8-9
8.1.7 Viewing the Information about M2000 Server Components

This function enables you to view the information of the components installed on the M2000 server that you log in to.
Procedure
Step 1 Choose Monitor > System Monitor > Browser. Step 2 In the System Monitor Browser window, click the Component Information tab. Step 3 View the information of all the installed components in Component Information tab. ----End
8.1.8 Saving the Monitoring Information

For the convenience of future analysis of the information that is monitored at certain time, you can save the required monitoring information to the server.
Procedure
Step 1 Choose Monitor > System Monitor > Browser. Step 2 In the System Monitor Browser window, click the tab of the monitoring information, and then click Save As.
NOTE
l l
The monitoring information can be saved in the format of TXT, HTML, CSV, or XML. The default format is XML.
Step 3 In the Save dialog box, select a storage path, enter the file name, and click Save. ----End
8.1.9 Setting Alarm Thresholds for the M2000

This section describes how to set the alarm thresholds for the M2000. On the M2000 client, you can set the alarm thresholds to monitor the server status. The monitoring of system status consists of server monitoring, disk monitoring, databases monitoring, and service monitoring. if the value of a parameter exceeds the threshold, the system generates the corresponding alarm.
Prerequisite
l l
Context
On the M2000, you can set the thresholds of certain parameters for the purpose of system monitoring. When the value of a parameter exceeds the threshold, the relevant record in the System Monitor Browser window is displayed in red. In addition, the corresponding alarm is generated.
Procedure
Step 1 In the main window, choose Monitor > System Monitor > Settings. The System Monitor Settings dialog box is displayed, as show in Figure 8-6. Figure 8-6 System Monitor Settings dialog box
Step 2 Select a monitoring item to set the thresholds. For details about the parameters for monitoring the server, see Table 8-1.
Issue 03 (2010-08-31)
8-11
Table 8-1 Server Monitor Name Server Monitor Parameter Settings CPU sustained overload times (10-400 times) Description Description:
l
Settings Value: Value range: 10-400 Default value: 40
The number of consecutive sampling times is equal to CPU sustained overload times. The sampling interval is equal to Server status refresh interval. If the CPU usage sampled each time is larger than the generation threshold, it means that the CPU is consecutively overloaded. When the number of overload times reaches the specified value, a high CPU usage alarm is generated. If the CPU usage sampled at a time is smaller than the clearance threshold, the high CPU usage alarm is cleared.
Server status refresh interval (2-60 seconds)
Description: Refresh interval for server monitoring, that is, the CPU usage is sampled every x seconds.
Value: Value range: 2-60 Default value: 15
8-12
Issue 03 (2010-08-31)
Name Server Monitor Threshold Settings CPU usage (%)
Description Description: Used to set Threshold for Alarm Generation, Threshold for Alarm Clearance for the CPU usage alarm and whether to enable the bubble. Memory usage (%) Used to set Threshold for Alarm Generation and Threshold for Alarm Clearance for the memory usage alarm.
l
Settings Value: Value range: 1-99. Default value: 90. Offset value range: 1-99. Default value: 70.
Value: Value range: 1-99. Default value: 95. Offset value range: 1-99. Default value: 85.
If the memory usage is larger than Threshold for Alarm Generation of Memory used rate, the M2000 generates a high memory usage alarm. If the memory usage is smaller than Threshold for Alarm Clearance of Memory used rate, the M2000 generates an alarm, prompting that the high memory usage alarm is cleared. When the function of bubble information is enabled, if the server is faulty, the system displays a bubble information.
Table 8-2 describes the parameters for monitoring the disks of the server.
Table 8-2 Hard Disk Monitor Name Disk Monitor Parameter Settings Hard disk status refresh interval (60-3600 seconds) Description Description: Refresh interval for hard disk monitoring. Description: All default thresholds of hard disk usage on the M2000 server.
l
Settings Value: Value range: 60-3600 Default value: 60 Value: Value range: 1-99 Default value of Threshold for Alarm Generation:
l l l l
Disk Monitor Threshold Settings
Default value setting (%)
When the hard disk usage is larger than Threshold for Alarm Generation of an alarm severity level, the M2000 generates a high hard disk usage alarm of this severity level. When the hard disk usage is smaller than Threshold for Alarm Clearance of an alarm severity level, the M2000 clears the high hard disk usage alarm of this severity level. When the function of bubble information is enabled, if the hard disk is faulty, the system displays a bubble information.
Warning: 60 Minor: 70 Major: 80 Critical: 90
Default value of Threshold for Alarm Clearance:

l l l l
8-14
Issue 03 (2010-08-31)
Name Advanced Setting (%)
Description Description: Thresholds of all the hard disk usage on the M2000 server.
l
Settings Value:
l
If you select Default value, the M2000 uses the threshold specified in Default value setting. If you select Customize value, the M2000 uses customized thresholds of alarms. Value range: 1-99. If you select Disable alarm generation, theM2000 doesn't report alarms of the disk partition.
Table 8-3 describes the parameters for monitoring the database of the server. Table 8-3 Database Monitor Name Database Monitor Parameter Settings Database status refresh interval (300-3600 seconds) Description Description: Interval of database refreshing. Settings Value: Value range: 300-3600 Default value: 300
Name Database Monitor Threshold Settings Default Value Setting (%)
Description Description: All default thresholds of database usage on the M2000 server.
l
Settings Value: Value range: 1-100 Default value:

l l l l
When the database usage is larger than Threshold of an alarm severity level, the M2000 generates a high database usage alarm of this severity level. When the database usage is smaller than Threshold of an alarm severity level, the M2000 clears the high database usage alarm of this severity level.
8-16
Issue 03 (2010-08-31)
Description Description: Thresholds for the database usage alarms of different severities. You need to set these thresholds separately for each database on the M2000 server.
l
Settings Setting method: Set the following parameters for each database:
l
Default Value: use default thresholds for the database usage alarms of different severities. Customize Value: customize thresholds for the database usage alarms of different severities. Value range: 1-100 Default value:

Disabled Monitoring: Disable the database monitoring.
Table 8-4 describes the parameters for monitoring the server services. Table 8-4 Service Monitor Name Services Monitor Parameter Settings Service status refresh interval (60-3600 seconds) Description Description: Interval of service refreshing. Settings Value: Value range: 60-3600 Default value: 60
Issue 03 (2010-08-31)
8-17
Name Service Monitor Screen Tip Settings Default Group
Description Description: Set whether to display the service status at the lower right corner of the M2000 system monitor client by or .
l If all the monitored
Settings Setting method: Select a service from the Service Name drop-down list. Select enable or disable in the corresponding Show Screen Tips dropdown list.
NOTE services are running, displayed. is
l if a monitored
service is stopped, is displayed.

l You can double-
click or to access the Service Monitor tab.
Step 3 Click OK. ----End
8.2 Querying the System Logs of the M2000

This section introduces the M2000 system log. System logs record the operation of the M2000 system. System logs also record the files and data tables of various types of information, which can be queried by the M2000 administrator.
Prerequisite
l l
Context
l
Querying the system logs requires only a few system resources and does not affect the system operation. System logs are saved in the following path on the M2000 server by default:
/opt/OMC/var/fileint/syslogs The save path of the system logs that are periodically exported is as follows: /opt/OMC/var/ThresholdExport/Log
8-18
If the log data in the database exceeds a preset threshold, the system exports the log data to a specific path.
l
The contents of the system logs:
Level: Risk, Minor, Info. System logs can be categorized into three levels in descending order. Source: Sources, such as FaultService, ServiceAdmin, and MediationService, are identified by the logos of the subsystems in the M2000 system. Time: Identifies the time when a system log is recorded. The date format is "Week/ Month/Day/Time/Timezone/Year", for example, Thu May 4 11:28:47 CST 2006. Basic information: Provides the basic information on system operation, such as the information about service startup. Details: Provides the details on system operation.
Procedure
Step 1 Choose System > Log Management > Query System Logs. The Filter dialog box is displayed. Step 2 Set the filtering conditions in the Filter dialog box, and then click OK. The Query System Logs window is displayed. Step 3 Double-click a record to view the detailed information. In the displayed Log Details dialog box, the system displays details about a successful operation or a failed operation. Step 4 Right-click a record and save the specified system logs as a file. You can save the system logs in one of the following formats: .txt, .html, .xls, .csv, and .pdf. ----End
8.3 Collecting NM Log Files

When the M2000 system fails, you can run the diagnostic tool to collect all the related diagnostic information from the M2000 Server and Client through the FTP protocol. When the M2000 client or server cannot run properly, you can collect all the operational information from the M2000 client or server to locate faults.
Context
By using this information, you can locate faults. The collected information includes:
l l
Trace files on the client, for example, Client_DebugTrace. Java virtual machine thread stack and lock state in client, for example, Client_ThreadStackDump.txt Trace files on the server, for example, iMAP.root.trace (to store the current trace files) and imap_stacks.20070206.170237.trace (to store the historical trace files collected before the NM log files) Core files on the server, for example, core.imapsvcd.0.21221.1170824184.stack File of alarm NE synchronization number, for example, FMSyncNo The pstack file, for example, imap_stacks.20070207.155817.trace.
l l l
Issue 03 (2010-08-31)

l
Information about the Sybase, for example, SybaseConfig.zip, SybaseVersion.zip, and SYBLog.20070206.171040.zip.
By default, the collected files are saved in M2000 client\client\diagnosis\collected files. You can change the save path.
l
The information collection progress is displayed in the Collection Details area of the Log Information Collector window. The M2000 diagnostic tool automatically collects diagnostic information from the client and then from the server.
Procedure
Step 1 Choose Programs > iManager M2000 Client > M2000 Log Information Collector. The Log Information Collector window is displayed. Step 2 In the Port Select window, select the M2000 client from which you need to collect information, and then click OK. If you have opened multiple M2000 clients concurrently, all the open clients are displayed in a list in the Port Select window. By performing this step, you can specify the client from which the diagnostic information is collected.
TIP
By comparing whether the process IDs in the PID column of the list with the progress ID of the target client, you can determine the client from which you will collect the diagnostic information. 1. Choose Start > Run. The Run dialog box is displayed. 2. Type taskmgr, and then click OK. The Windows Task Manager dialog box is displayed. 3. Click the Processes tab. 4. Choose View > Select Columns. The Select Columns dialog box is displayed. 5. Select the PID (Process Identifiers) check box, and then click OK. 6. Click the Applications tab. 7. Right-click the M2000 client to be viewed, and then choose Go To Process from the shortcut menu. 8. In the Port Select window, select the column where the value of PID is the same as the value displayed in the PID column.
Step 3 Configure the FTP server. 1. 2. 3. Enter the IP address of the M2000 server. Enter the port number. Enter the FTP user name and password for logging in to the target server.
Step 4 Select the information to be collected. For details, see Parameters for Collecting NM Logs Parameters.
l
To collect the trace files on the client, trace files on the server, core files on the server, or trace files on the LMT, you need to set Start Time and End Time to collect the information within the specified time range. To collect alarm localization information, you need to enter the name of the NE whose alarm localization information needs to be collected in NE Name.
Step 5 Set the folder for saving the diagnostic information. The collected files are saved under M2000 client installation directory\client\diagnosis \collected files. You can modify the directory for saving collected files.
Step 6 Click Collect to collect the diagnostic information.

l
If you click Stop when collecting the diagnostic information from a client, do not stop the progress of collecting information from the client. If you click Stop when collecting the diagnostic information from the M2000 server, the diagnostic information about the server cannot be obtained. To view the collected diagnostic information, you can click Browse to navigate the directory of the collected files.
----End
8.4 Querying NE Subareas

This section describes how to query NE subareas. An NE subarea refers to the M2000 server that manages the NE. If the M2000 server adopts the SUN SLS solution or the ATAE cluster system solution, NEs can be managed by different servers (subareas). On the M2000 client, you can query different NE subareas.
Prerequisite
You have logged in to the M2000 client.
Procedure
Step 1 Choose System > Query NE SubArea to open the Query NE Subarea window. Step 2 Select a query condition, and then click Query. You can query NE subareas based on NE subareas or NE names.
l
Querying NE subareas based on NE subareas: In the Query Result dialog box, the NE distributions and NE information such as No, NE Name, NE Version, and Number of NEs are displayed. In the Statistic dialog box, the subarea information such as IP addresses and database instance names are displayed. Querying NE subareas based on NE names: In the Query Result dialog box, the NE distributions and NE information such as No, NE Name, NE Version, and Number of NEs are displayed. In the Statistic dialog box, the subarea information such as IP addresses and database instance names are displayed.
NOTE
You can click Save to save the query results as a file.
For the detailed parameter description, see 8.8.3 Parameters for the NE Partitioning Information. ----End
8.5 Managing the M2000 License

M2000 licenses can restrict the number of manageable devices, and the availability duration of the M2000. You need to manage the licenses periodically. 8.5.1 Querying the M2000 License This section describes how to query the license file on the M2000 server through the M2000 client.
8.5.2 Updating the M2000 License This section describes how to replace the M2000 license file on the M2000 server through the client.
8.5.1 Querying the M2000 License

This section describes how to query the license file on the M2000 server through the M2000 client.
Procedure
Step 1 Choose License > OMC License Management > License Information. Step 2 In the License Information dialog box, query the license information about resources and functions on the Resource control item and Function control item tabs. ----End
8.5.2 Updating the M2000 License

This section describes how to replace the M2000 license file on the M2000 server through the client.
Context
l l l
The type of the license applied for must be consistent with the version type. Before the licenses expire, the M2000 displays a warning periodically. The valid time for the license that is uniformly used in M2000 contains two fields: Expiry (Days) and End Time. If both the fields exist, the value of Expiry(Days) is valid.
Procedure
Step 1 Choose License > OMC License Management > License Information. Step 2 In the License Information dialog box, click Update License. Step 3 In the Open dialog box, select the new license file, and then click Open. Step 4 In the License Comparison Results dialog box, view the changes of the licenses, and then click OK. ----End
8.6 Check OMC status

OMC check is used to check the status of the M2000. This check also exports check reports in .html format. The OMC check enables you to find the hidden problems of devices. Thus, severe accidents are avoided and proper operation of current devices is ensured.
Prerequisite
l l
You have logged in to the M2000 successfully. You are authorized to perform associated operations.
8-22
Procedure
Step 1 Choose Maintenance > Task Management. The Task Management window is displayed. Step 2 Click New or double-click OMC Check node. Step 3 In the displayed New Task dialog box, set the basic information of the task. 1. 2. In the Task Name field, enter the name of the task. From the Run Type drop-down list, select Once or Period.
Step 4 Click Next. Step 5 Then, set the start time of the task. To set the start time of the task, perform the following operations:
l l l
In the Start Time field, enter the start time. Click Click
NOTE
or
to adjust the time.
. In the displayed Date/Time Selection dialog box, set the start time.
The Start Time must be later than the current system time.
Step 6 Perform different operations based on task types. Task Type Steps
One-time task Perform Step 7. Periodic task

l
In No. of periods and No. of run times fields, enter the associated information. Then, perform Step 7. In No. of periods and End time fields, enter the associated information. Then, perform Step 7.
Step 7 Click Next. Then, set the information about OMC check. Step 8 Click Finish. The progress bar displays the progress of file upload. After the upload is complete, the new device check task is displayed on the task list. ----End
8.7 Integrated Task Management

The M2000 provides the function of integrated management of scheduled tasks. Thus, you can browse information such as the task status and the progress. You can also create, modify, and delete user-scheduled tasks. In addition, you can suspend, restore, cancel scheduled tasks, and save task result files to the client. 8.7.1 Overview of Integrated Task Management The integrated task management integrates the concepts such as types of integrated tasks, task scheduling parameters, states of timing tasks. The knowledge of integrated task management helps you perform the operations related to the integrated task management.
8.7.2 Customizing the Interface for Managing Timing Tasks This describes how to customize the interface for managing timing tasks. The system can display timing tasks of the specified function type in the navigation tree or display the timing tasks meeting the condition in the task list. 8.7.3 Creating a User Timing Task This topic describes how to create a user timing task. Parameter setting varies according to different tasks. 8.7.4 Modifying a Timing Task This section describes how to modify the attributes of a user timing task or a system timing task. 8.7.5 Managing Timing Tasks User timing tasks refer to those timing tasks managed by the user. The user can delete, suspend, resume, cancel, terminate, and roll back user timing tasks. 8.7.6 Browsing the Information of Timing Tasks On the M2000, you can browse information about timing tasks such as the task name, user name, process, and execution result according to your own permissions. 8.7.7 Viewing the Task Execution You can view the last execution results of a timing task. 8.7.8 Viewing the Task History You can view the last execution history of a timing task. 8.7.9 Downloading Task Execution Tasks You can download the execution file of NodeB license allocation tasks to a local PC and then check the specific resource allocation information. 8.7.10 Downloading Result Files This describes how to download the results of timing tasks. You can save the results of timing tasks on the server to the local client in .txt format.
8.7.1 Overview of Integrated Task Management

The integrated task management integrates the concepts such as types of integrated tasks, task scheduling parameters, states of timing tasks. The knowledge of integrated task management helps you perform the operations related to the integrated task management.
Types of Centralized Tasks

The M2000 classifies managed scheduled tasks into different types according to the task execution period, function, and feature.
Tasks Grouped According to the Execution Period

According to the execution period, the M2000 classifies managed scheduled tasks into one-time tasks and periodic tasks. Table 8-5 describes each type of task.
8-24
Issue 03 (2010-08-31)
Table 8-5 Tasks grouped according to the execution period Types of Centralized Tasks Once Period Description Refers to a task that is performed only once at a specified time. Refers to a task that is performed periodically since a specified time.
Tasks Grouped According to the Function

According to the task function, the M2000 classifies managed scheduled tasks into database capacity management tasks, file interface tasks, manual dump tasks, overflow dump tasks, NE Information Collector (NIC) tasks, synchronization tasks, backup tasks, CM report tasks, CME tasks, NE health check (NHC) tasks, and other tasks. Table 8-6 describes each type of task.
NOTE
The NEs that support CME tasks are the RNC, NodeB, BSC6000, BSC6900 GSM, BSC6900 UMTS and BSC6900 GU.CME tasks are available only after the CME software corresponding to the NE version is installed.
Table 8-6 Tasks grouped according to the function Types of Centralized Tasks Database Capacity Management Description The M2000 periodically deletes the data whose storage duration reaches the specified Save Days from the database. Database capacity management tasks ensure that the database capacity is maintained within a proper range, thus avoiding database faults caused by insufficient database capacity. By default, the maximum Save Days in the database is 90 days. The customized value cannot exceed 90 days. The data that can be managed by the M2000 consists of M2000 operation logs, M2000 system logs, M2000 security logs, NE operation logs, NE system logs, NE security logs, alarm/event logs, and performance data. File Interface Various types of data is periodically exported to a specified directory on the server. You can save data outside the system by using this function. The exported data is still stored in the database. The data that can be exported consists of performance data, configuration data, alarm/event logs, NodeB license data, NE upgrade logs, NE inventory data, NE operation logs, NE security logs, NE system logs, M2000 operation logs, M2000 system logs, and M2000 security logs.
Issue 03 (2010-08-31)
8-25
Types of Centralized Tasks NIC
Description NIC tasks provide the Nastar with the NE data required for analyzing system performance, querying and verifying configuration data, scanning uplink frequencies, and optimizing neighboring cells. NIC tasks are classified into the following types:
l
2G/3G Neighboring Cell Optimization: These tasks are used for collecting the information about neighboring GSM cells for 3G neighboring relation analysis. GSM MR Data Collection: These tasks provide the performance analysis tool with MR data for network optimization analysis. These tasks are controlled by the M2000 license. NIC Configuration Data Export: These tasks provide the Nastar with NE configuration data for NE configuration data query and verification. RTWP Data Collection: These tasks provide the Nastar with NodeB interference data. Daemon NIC Task: These tasks provide the Nastar with various types of data, such as the interference data, intra-frequency neighboring cell optimization data, complaint handling data of the CDMA network, and the intra-frequency neighboring cell optimization data and coverage analysis data of the UMTS network. Network Logs Collection: These tasks are used for collecting the CHR logs of WiMAX BTSs and eNodeBs and neighboring cell relation logs and interference logs of WiMAX BTSs, thus providing the Nastar with the data about abnormal call events, terminal switch events, and base station frequency interference. Basic NE Information Export: These tasks are used for collecting basic NE information for the Nastar. Frequency Scan: These tasks provide the Nastar with uplink frequency data for uplink interference analysis. These tasks are controlled by the M2000 license. Neighboring Cell Optimization: These tasks provide the Nastar with neighboring cell optimization data for neighboring cell analysis. These tasks are controlled by the M2000 license.
8-26
Issue 03 (2010-08-31)
Types of Centralized Tasks Others
Description Other tasks are classified into the following types:

l
MML Script: After an MML script is configured, the M2000 issues the commands in the script in batches on a scheduled basis. Therefore, you need not manually issue the commands one by one. NodeB License Timed Distribution: The M2000 performs scheduled tasks for allocates NodeB license resources at a specified time, thus reducing manual operations. PRS Scheduled Task: You can set PRS scheduled tasks on the M2000 for the required performance reports. Then, the M2000 collects performance data and generates performance reports on a scheduled basis. BSC/RNC License Timed Activation: The M2000 performs scheduled tasks for downloading and activating BSC/RNC license files at a specified time, thus reducing manual operations. OMC Check: The M2000 checks its devices and generates a check report in .html format on a scheduled basis. Therefore, hidden problems of devices can be identified and severe accidents can be avoided. RSSI Test: The M2000 collects the RSSI values of base stations in a scheduled basis. Therefore, exceptions in the base station radio frequency (RF) subsystem can be identified in time and voice quality can be ensured. Performing an RSSI test task consumes a large number of system resources. Therefore, you are advised to perform such a task only for batch test. Currently, only CBTSs support RSSI test tasks. Upgrade Checking: The M2000 checks whether the services are functioning normally after an NE is upgraded. Dual Home Auto Consistency Management: The M2000 checks the data of NEs that have the dualhoming relation periodically or on a scheduled basis, thus enabling you to check NE data consistency and to ensure that an MSC server can take over some or all data on the other MSC server in case of a dual-homing failover. Alarm Check: The M2000 analyzes NE alarm trends, comparisons between alarms, TopN alarm features, alarm maintenance, and fault alarms and generates check reports in .html format on a scheduled basis, thus enabling you to analyze network faults in detail. PM Synchronization: The M2000 periodically synchronizes NE objects to ensure that the performance measurement (PM) objects on the M2000 are consistent with those on NEs.
8-27
Issue 03 (2010-08-31)
Types of Centralized Tasks
Description
l
Top Power Test: The M2000 collects the value of the transmit power on top of the cabinet on a scheduled basis. Therefore, exceptions in the base station RF subsystem can be identified in time and voice quality can be ensured. Performing a top power test task consumes a large number of system resources. Therefore, you are advised to perform such a task only for batch test. Currently, only CBTSs support top power test tasks. NE Software Download: The M2000 instructs an NE to download the corresponding NE mediation software from the M2000 server periodically or on a scheduled basis to ensure that the NE version is delivered to the NE at the specified time. Script Timer Task: By running the preset HSL scripts, you can perform operations such as modifying NE parameters and obtaining alarm data.
Synchronization
Certain data may be missing due to causes such as communication interruption. The synchronization function enables you to ensure that the data on the M2000 is consistent with the data on NEs.
l
The M2000 obtains the latest data from NEs on a scheduled basis by performing an NE configuration data synchronization task, NE log synchronization task, NE upgrade log synchronization task, NE inventory data synchronization task, or alarm scheduled synchronization task. Through a maintenance mode synchronization task, the NE maintenance mode information stored on the M2000 is delivered to NEs on a scheduled basis.
Backup
The M2000 allows you to save server data and NE data in backup files to a specified directory on the M2000 server. The stored server data and NE data can be used for restoring the system and NEs in case of any data loss or any exception in the system and NEs. Backup tasks are classified into the following types:
l
NE Backup: The configuration files stored on NEs and the files that dynamically change during NE operation can be backed up. Server Backup: The dynamic service data of the M2000 system can be backed up. The operating system, however, cannot be backed up. NE License Backup: Only the currently activated license files on NEs can be backed up.
8-28
Issue 03 (2010-08-31)
Types of Centralized Tasks CM Report
Description The M2000 periodically exports configuration reports in files to a specified directory on the M2000 server. You can use this function to save data outside the system. The exported data is still stored in the database. The types of reports that can be exported consist of RAN report, core network resource report, NE report, NE statistic report, and NE link report.
CME
CME tasks are classified into the following types:

l
CME Upload: The M2000 uploads the selected NE configuration data to the CME server periodically or on a scheduled basis to ensure that the CME obtains the latest NE data for data configuration. Cell Parameters Compare: The M2000 compares the parameters in the current data area with the default parameters in the CME configuration template and then exports the comparison results to the default path. Cell Consistency Check: The M2000 checks whether the data in the current data area complies with the selected check rules. Currently, the rules for checking unidirectional neighboring cells and cell consistency are provided. Current Area Export: The M2000 exports the required data from the current data areas through northbound interfaces, thus facilitating current data area management.
NHC
Pre-alarm Handling Task: The M2000 checks whether the mediation or the current NE is normal and generates a report on a scheduled basis.
Tasks grouped according to the feature

According to the task feature, the M2000 classifies managed scheduled tasks into system scheduled tasks and user scheduled tasks. Table 8-7 describes each type of task. Table 8-7 Tasks grouped according to the feature Types of Centralized Tasks System Scheduled Task Description System scheduled tasks are the tasks required for the normal operation of the M2000 system. For details about these tasks, see System Scheduled Tasks. User scheduled tasks are the tasks customized to meet the requirements of network maintenance. For details about these tasks, see User Scheduled Task.
User Scheduled Task
Issue 03 (2010-08-31)
8-29
System Scheduled Tasks

System scheduled tasks are created during the installation or upgrade of the M2000 system. The Creator parameter of each system scheduled task is displayed as OMC. The M2000 uses tasks.
NOTE
to identify system scheduled tasks and uses
to identify user scheduled
l l l
Only users in the administrator group can manage and view system scheduled tasks. System scheduled tasks cannot be copied. Only some parameters of system scheduled tasks can be modified. These parameters, however, cannot be deleted. In system scheduled tasks, database capacity management tasks cannot be suspended or canceled, while synchronization tasks and backup tasks can be suspended or canceled. You can also set the time when a synchronization task or backup task will be suspended or canceled.
For details about system scheduled tasks, see Table 8-8. Table 8-8 Description of system scheduled tasks Task Type Database Capacity Management Task Name Alarm/Event Log Dump Performance Data NE Operation Log NE Security Log NE System Log NM Operation Log Dump NM System Log Dump NM Security Log Dump File Interface Performance Data Export Configuration Data Export NodeB License Data Export NE Upgrade Log Export For details, see 8.8.18 Parameters for Modifying the Export of Performance Data. For details, see 8.8.19 Parameters for Modifying a Configuration Data Export Task. For details, see 8.8.14 Parameters for Setting Common Parameters for Timing Tasks. For details, see 8.8.39 Parameters for Creating/Modifying/Copying the Export of NE Upgrade Log.
Issue 03 (2010-08-31)
Reference For details, see 8.8.17 Parameters for Modifying a Database Capacity Management Task.
8-30
Task Type
Task Name NE Operation Log Export NE System Log Export NE Security Log Export Inventory Data Export Alarm/Event Log Export NM Operation Log Export NM System Log Export NM Security Log Export
Reference For details, see 8.8.20 Parameters for Modifying the Export of NE Logs.
For details, see 8.8.21 Parameters for Modifying the Export of Inventory Data. For details, see 8.8.22 Parameters for Modifying an Alarm/Event Log Export Task. For details, see 8.8.23 Parameters for Modifying the Export of M2000 Logs.
Overflow Dump
Alarm Overflow Dump Event Overflow Dump
For details, see Parameters for Setting Alarm/ Event Overflow Dump.
Manual Dump
Alarm Manual Dump Event Manual Dump
For details, see Parameters for Dumping Alarms/Events Manually. For details, see 8.8.19 Parameters for Modifying a Configuration Data Export Task. For details, see 8.8.24 Parameters for Modifying NE Basic Information Export Task. For details, see Parameters for Modifying Network Log Data Collection Tasks. For details, see 8.8.14 Parameters for Setting Common Parameters for Timing Tasks. For details, see 8.8.25 Parameters for Modifying the Synchronization of NE Configuration Data . For details, see 8.8.14 Parameters for Setting Common Parameters for Timing Tasks.
NIC
NIC Configuration Data Export NE Basic Information Export Network Logs Collection
Other Synchronization
PM Object Synchronization NE Configuration Data Synchronization NE Log Synchronization
Issue 03 (2010-08-31)
8-31
Task Type
Task Name Inventory Data Synchronization Alarm Synchronization Maintenance Mode Synchronization NE Upgrade Log Synchronization
Reference For details, see 8.8.26 Parameters for Modifying the Synchronization of Inventory Data. For details, see 8.8.14 Parameters for Setting Common Parameters for Timing Tasks. For details, see 8.8.14 Parameters for Setting Common Parameters for Timing Tasks. For details, see 8.8.14 Parameters for Setting Common Parameters for Timing Tasks. For details, see 8.8.27 Parameter Description: Modifying a Data Backup Task of the M2000.
Backup
Server Backup
User Scheduled Task

User scheduled tasks are tasks customized to meet the requirements of network maintenance.
l l
You can create, modify, delete, copy, suspend, or restore user scheduled tasks. The M2000 uses scheduled tasks. to identify system scheduled tasks and uses to identify user
For details about user scheduled tasks, see Table 8-9.

NOTE
The NEs that support CME tasks are the RNC, NodeB, BSC6000, BSC6900 GSM, BSC6900 UMTS and BSC6900 GU. CME tasks are available only after the CME software corresponding to the NE version is installed.
Table 8-9 Description of user scheduled tasks Task Type Backup Task Name NE Backup Description The M2000 saves NE data in backup files to a specified directory on the server periodically or on a scheduled basis. The backup files are used for restoring NEs in case of any data loss or NE exception. You can back up the data of the NEs on the entire network, NEs of a specified type, or specified NEs. Reference For details, see 8.8.28 Parameters for Creating/ Modifying/Copying NE Backup.
8-32
Issue 03 (2010-08-31)
Task Type
Task Name NE License Backup
Description The activated license files on NEs are backed up and uploaded to a specified directory on the M2000 server on a scheduled basis. The license files are used for restoring NEs in case of any license file loss or NE exception. The M2000 periodically exports configuration reports in files to a specified directory on the M2000 server. You can use this function to save data outside the system. The exported data is still stored in the database.
Reference None.
CM Report
RAN Report Export Core Network Resource Report Export NE Report Export NE Statistic Report Export Link Report Export
For details, see 8.8.30 Parameters for Creating, Modifying, or Copying a Configuration Report Export Task.
NIC
2G/3G Neighboring Cell Optimization
These tasks are used for collecting the information about neighboring GSM cells for 3G neighboring relation analysis. This task is created on the Nastar. You only need to view the task progress on the M2000.
None.
GSM MR Data Collection
These tasks provide the performance analysis tool with MR data for network optimization analysis. These tasks are controlled by the M2000 license. These tasks provide the Nastar with NodeB interference data. This task is created on the Nastar. You only need to view the task progress on the M2000.
For details, see Parameters for Creating a GSM MR Data Collection Task.
RTWP Data Collection
None.
Issue 03 (2010-08-31)
8-33
Task Type
Task Name Daemon NIC Task
Description These tasks provide the Nastar with various types of data, such as the interference data, intrafrequency neighboring cell optimization data, complaint handling data of the CDMA network, and the intra-frequency neighboring cell optimization data and coverage analysis data of the UMTS network. This task is created on the Nastar. You only need to view the task progress on the M2000.
Reference None.
Frequency Scan
These tasks provide the Nastar with uplink frequency data for uplink interference analysis. These tasks are controlled by the M2000 license. These tasks provide the Nastar with neighboring cell optimization data for neighboring cell analysis. These tasks are controlled by the M2000 license. After an MML script is configured, the M2000 issues the commands in the script in batches on a scheduled basis. Therefore, you need not manually issue the commands one by one. The M2000 performs scheduled tasks for allocates NodeB license resources at a specified time, thus reducing manual operations. You can set PRS scheduled tasks on the M2000 for the required performance reports. Then, the M2000 collects performance data and generates performance reports on a scheduled basis.
For details, see Parameters for Creating a Task of Collecting the Uplink ARFCN Data. For details, see Creating a Data Collection Task for Neighbor Cell Optimization.
Neighboring Cell Optimization
Other
MML Script
For details, see 8.8.29 Parameters for Creating/ Modifying/Copying MML Command Script.
NodeB License Timed Distribution
For details, see 8.8.32 Parameters for Creating/ Modifying/Copying Scheduled NodeB License Allocation Tasks. For details, see 8.8.31 Parameter Description: Creating, Viewing, or Modifying a Scheduled Report Task.
PRS Scheduled Task
8-34
Issue 03 (2010-08-31)
Task Type
Task Name BSC/RNC License Timed Activation
Description The M2000 performs scheduled tasks for downloading and activating BSC/RNC license files at a specified time, thus reducing manual operations. The M2000 checks its devices and generates a check report in .html format on a scheduled basis. Therefore, hidden problems of devices can be identified and severe accidents can be avoided. The M2000 collects the RSSI values of base stations in a scheduled basis. Therefore, exceptions in the base station radio frequency (RF) subsystem can be identified in time and voice quality can be ensured. Performing an RSSI test task consumes a large number of system resources. Therefore, you are advised to perform such a task only for batch test. Currently, only CBTSs support RSSI test tasks.
NOTE The portals of the RSST Test task are as follows:
l Maintenance > Task
Reference For details, see 8.8.33 Parameters for Creating/ Modifying/Copying Scheduled BSC or RNC License Allocation Tasks. For details, see 8.8.45 Parameters for Selecting Objects for OMC Check.
OMC Check
RSSI Test
For details, see 8.8.35 Parameters for Creating/ Modifying/Copying an RSSI Test Task.
Management.
l Maintenance > RF
Performance Test > RSSI Test.
Upgrade Checking
The M2000 checks whether the services are functioning normally after an NE is upgraded. NE mediation software is downloaded from the M2000 server to a specified NE periodically or on a scheduled basis to ensure that the NE version can be delivered to the NE at the specified time.
For details, see Parameters for Creating an NE Upgrade Verification Task. For details, see 8.8.36 Parameters for Creating/ Modifying/Copying Software Download.
NE Software Download
Issue 03 (2010-08-31)
8-35
Task Type
Task Name Dual Home Auto Consistency Check Management
Description The M2000 checks the data of NEs that have the dual-homing relation periodically or on a scheduled basis. Therefore, you can ensure that an MSC server can take over some or all data on the other MSC server in case of a dual-homing failover. The M2000 analyzes NE alarm trends, comparisons between alarms, TopN alarm features, alarm maintenance, and fault alarms and generates check reports in .html format on a scheduled basis, thus enabling you to analyze network faults in detail. The M2000 collects the value of the transmit power on top of the cabinet on a scheduled basis. Therefore, exceptions in the base station RF subsystem can be identified in time and voice quality can be ensured. Performing a top power test task consumes a large number of system resources. Therefore, you are advised to perform such a task only for batch test. Currently, only CBTSs support top power test tasks.
NOTE The portals of the Top Power Test task are as follows:
l Maintenance > Task
Reference For details, see 8.8.37 Parameters for Creating/ Modifying/Copying a Dual-Homing Auto Consistency Check Task.
Alarm Check
For details, see Parameters for Setting Special Alarm Check Tasks.
Top Power Test
For details, see 8.8.34 Parameters for Creating/ Modifying/Copying a Task for Testing BTS Cabinet-Top Power.
Management.
l Maintenance > RF
Performance Test > Top Power Test.
Script Timer Task
By running the preset HSL scripts, you can perform operations such as modifying NE parameters and obtaining alarm data.
For details, see 8.8.38 Parameters for Creating/ Modifying/Copying an HSL Script Task.
8-36
Issue 03 (2010-08-31)
Task Type CME
Task Name CME Upload
Description You can set a specified interval or a time to upload user-selected NE configuration data to the CME server. Therefore, the CME can obtain the latest NE data for data configuration. The M2000 compares the parameters in the current data area with the default parameters in the CME configuration template and then exports the comparison results to a specified path. The M2000 checks whether the data in the current data area complies with the selected check rules. Currently, the rules for checking unidirectional neighboring cells and cell consistency are provided. The M2000 exports the data in the current data area through northbound interfaces, thus facilitating the management of the current data area. The M2000 checks whether the mediation or the current NE is normal and exports a report on a scheduled basis.
Reference For details, see 8.8.40 Parameters for Creating/ Modifying/Copying a CME Upload Task.
Cell Parameters Compare
For details, see 8.8.41 Parameters for Creating/ Modifying/Copying Cell Parameters Compare Task.
Cell Consistency Check
For details, see 8.8.42 Parameters for Creating/ Modifying/Copying Cell Consistency Check Task.
Current Area Export
For details, see 8.8.43 Parameters for Creating/ Modifying/Copying a CME Current Area Export Task. None.
NHC
Pre-alarm Handling Task
Task Scheduling Parameters

The task scheduling parameters are the parameters related to the task execution type, task start time, task execution period, and execution times. Table 8-10 describes the task scheduling parameters.
Issue 03 (2010-08-31)
8-37
Table 8-10 Description of the task description parameters Parameter Task Type Description According to different task execution periods, the M2000 divides the execution types of the managed timing tasks into two types: periodic execution and one-time execution. The execution type of the system timing tasks is periodic execution. The execution type of user timing tasks can be periodic execution or one-time execution. Indicates start time of periodic tasks and one-time tasks set during task creation, including date and time. The start time of tasks should be later than the current server time.
l
Start Time
Period
Interval between periodic tasks. It has two enlistments: unit and duration. The unit of Period can be month, week, day, hour, or minute. Second is not supported. The supported units of Period vary according to the task type. The task execution period can be represented by month, week, day, hour, and minute. Second is not supported. The supported units vary according to the task type. The period interval range is as follows: 1 to 12 for month, 1 to 52 for week, 1 to 366 for day, 1 to 366x24 for hour and 1 to 366x24x60 for minute.
Run Times
Indicates execution times of a periodic task. The execution times range from 0 to 65535. The value 0 indicates no limit.
NOTE
Assume that the scheduling parameters of the entire network NE backup task are:
l l l l
Execution type = Periodicity Start time = 2006-10-21 09:07:28 Execution period = 1 day Period execution times = 0
The preceding information indicates that the system executes the entire network NE backup task at 09:07:28 every day from 09:07:28 on Oct. 21, 2006.
States of a Timing Task

A timing task has five states: idle, running, suspend, archived and finished. The states of a scheduled task change with different operations. For details, see Figure 8-7.
8-38
Issue 03 (2010-08-31)
Figure 8-7 State transition of a scheduled task

Start Creating a timing task Idle
Suspend a timing task
Restore a timing task
Scheduling
Cancel Finish Yes
Running
Deleting a timing task
Suspend
Terminate a CME task
Terminate a CME task
Another Scheduling? Scheduling No
D tim ele in ting g ta sk
ete Del task ME aC
Archived
Ter a C minate ME task

Finished
Deleting a timing task End
State transition of a scheduled task is as follows:

l l l l l l
A scheduled task is in the idle state after it is initially created. An idle task is changed to the running state after being scheduled. An idle task is changed to the suspended state after being suspended. A running task is changed to the idle state after being cancelled. A suspended task is changed to the idle state after being resumed. If a task need not be scheduled after being performed, it is in the finished state. If it needs to be scheduled again, it returns to the idle state.
If a CME task is in the finished state and you terminate the task, the CME task is in the archiving state. When a timing task is in the idle, suspended, or finished state and a CME task is in the archiving state, you can delete the user timing task. Users except admin can delete only the tasks created by themselves. The admin can delete the tasks created by all users.
8.7.2 Customizing the Interface for Managing Timing Tasks

This describes how to customize the interface for managing timing tasks. The system can display timing tasks of the specified function type in the navigation tree or display the timing tasks meeting the condition in the task list.
Prerequisite
Procedure
Step 1 Choose Maintenance > Task Management. Step 2 In the Task Management window perform different operations according to different customized requirement. Customized Requirement Operation
Customize the navigation tree 1. Right-click in the navigation tree and choose Filter Type from the shortcut menu. The Filter Type dialog box is displayed. 2. Select the timing task type to be displayed. By default, all the timing task types that the current user is authorized to browse are displayed. Customize the task list 1. Right-click the task list and select Filter Task. The Filter Task dialog box is displayed. 2. Set the User Name, Category, Task State, and Last Run Result as the filtering conditions. For detailed parameter description, refer to 8.8.12 Parameters for Setting Task Filter Conditions. Step 3 Click OK. ----End
8.7.3 Creating a User Timing Task

This topic describes how to create a user timing task. Parameter setting varies according to different tasks.
Prerequisite
You have logged in to the M2000 client successfully.
Context
l
To quickly create a task, you can copy a multi-instance user timing task of user and then modify its parameters. The instance quantity of the timing tasks of a specific type is restricted. If the instance quantity of the existing timing tasks of a type reaches the maximum, you cannot create or copy a timing task of this type.
Procedure
Step 1 Choose Maintenance > Task Management. Step 2 In the Task Management window, create a user timing task. You can create a user timing task by using one of the following methods:
l
In general, click New.

8-40

l
To quickly create a task of the specified type, double-click a user timing task in the Task Type navigation tree. To quickly create a multi-instance user timing task whose parameter settings are similar to those of the specified task, select the specified multi-instance user timing task, and then click Copy.
Step 3 In the New Task or Copy Task dialog box, set the parameters of the created user timing task. Option Parameter Common Parameters Description Setting 1. Set Task Name, Task Type, and Run Type. Do as follows:
l l
Task Name: Enter the task name in Task Name. Task Type: Select the type of the task to be created in the Task Type navigation tree. Run Type: Select Once or Period in the Run Type area.
NOTE The value of Run Type for part of tasks is fixed to Once or Period because of their task types.
2. Click Next. 3. Set Start Time and Period Setting. Do as follows:

l l
Start Time: In the Time Setting area, set Start Time. Period Setting: In the Period Setting area, set Period, and then select a periodic execution mode, namely, Run times or End time.
l For a one-time task, you can select Run At Once. After the task is created, it runs
NOTE at once.
l For a periodic task, you need to set the parameters in the Period Setting area.
Extended Parameters Step 4 Click Finish.
Set extended parameters according to the task requirements.
The created user timing task is displayed in the task list. ----End
8.7.4 Modifying a Timing Task

This section describes how to modify the attributes of a user timing task or a system timing task.
Prerequisite
You have logged in to the M2000 client successfully.
Context
Timing tasks are classified into System Scheduled Tasks and User Scheduled Task.
Procedure
Step 1 Choose Maintenance > Task Management. Step 2 In the Task Management window, modify the attributes of a timing task. You can modify a timing task by using one of the following methods:
NOTE
Parameter modification varies according to the task type.

l
Select a task from the task list, and then click Attribute. In the Attribute dialog box, modify common and extended parameters. Double-click a task in the task list. In the displayed Attribute dialog box, modify common and extended parameters.
Step 3 Click Finish. ----End
8.7.5 Managing Timing Tasks

User timing tasks refer to those timing tasks managed by the user. The user can delete, suspend, resume, cancel, terminate, and roll back user timing tasks.
Suspending Timing Tasks

To delay the time for scheduling a task, you can suspend an idle timing task. After a task is suspended, it is changed to the suspended state.
Prerequisite
l l
You have logged in to the M2000 client. At least one idle timing task exists.
Context
The M2000 can execute the tasks that are not suspended only through scheduling.
Procedure
Step 1 Choose Maintenance > Task Management. Step 2 In the Task Management window, select Task Type in the navigation tree. Step 3 Suspend one or more idle tasks with one of the following methods:
l
Manual suspending Select one or more tasks in the task list. Right-click the task and select Suspend. In the Confirm dialog box, click Yes.
Automatic suspending Select a task in the task list. Right-click the task and select Timely Suspend/Resume. In the Timely Suspend/Resume dialog box, select Suspend Time and then specify the time. Click OK.
----End
Resuming Timing Tasks

You can resume a suspended task. After that, the task becomes idle and is ready to be dispatched by the system.
Prerequisite
l l
You have logged in to the M2000 client. At least one suspended scheduled task exists.
Context
Only idle tasks can wait to be used.
Procedure
Step 1 Choose Maintenance > Task Management. Step 2 In the Task Management window, select Task Type in the navigation tree. Step 3 Resume the suspended task with one of the following methods:
l
Manual resuming Select one or more tasks in the task list in the right pane. Right-click the task and select Resume. In the Confirm dialog box, click Yes.
Automatic resuming Select a task in the task list in the right pane. Right-click the task and select Timely Suspend/ Resume. In the Timely Suspend/Resume dialog box, select Resume Time and then specify the time. Click OK.
----End
Setting Time of Timing Tasks

You can set an automatic suspend time or an automatic restore time for a scheduled task. In this situation, the M2000 automatically suspends the task or restores the task.
Prerequisite
l l
You have logged in to the M2000 client. At least one suspended or idle timing task exists.
Context
l
The system suspends an idle task and delay the time for using this task. If the timing task is not in the Idle state at the specified time, it fails to be suspended. In the specified time, the system resume a suspended task and then the task is in the idle status and wait to be dispatched. If the timing task is not in the Idle state at the specified time, it fails to be suspended. You are not allowed to set auto-suspend or resume a Running timing task.
Issue 03 (2010-08-31)
Procedure
Step 1 Choose Maintenance > Task Management. The Task Management window is displayed. Step 2 In the navigation tree, select the task type of which you plan to suspend. Step 3 From the task list in the right part of the window, select a timing task to be suspended. Step 4 Right-click the task and choose Timing Suspend/Resume. Step 5 In the displayed Timing Suspend/Resume dialog box, select Suspend Time or Resume Time as required. Step 6 Set the suspend time or resume time. For details of setting an automatic suspend time or an automatic restore time, refer to 8.8.44 Parameters for Setting Time of Timing Tasks. ----End
Cancelling Timing Tasks

You can cancel a running task. The task status is changed to idle after being cancelled.
Prerequisite
l l
You have logged in to the M2000 client. At least one Running timing task exists.
Context
A user in the common user group can cancel only the tasks created by himself. A admin can cancel the timing tasks created by all users.
Procedure
Step 1 Choose Maintenance > Task Management. Step 2 In the Task Management window, select Task Type in the navigation tree. Step 3 Select one or more running tasks in the task list in the right pane. Right-click the task and select Cancel. Step 4 In the Confirm dialog box, click Yes. Then the status of the task is changed from running to idle. ----End
Deleting Timing Tasks

You can delete the tasks created by yourself according to the actual requirements to save system resources.
Prerequisite
l

8-44

l
At least one timing task exists.
Context
l
Users can delete only the tasks created by themselves. The admin can delete the tasks created by all users. System tasks cannot be deleted. Running tasks cannot be deleted. You can delete only an Archived CME download task.
l l l
Procedure
Step 1 Choose Maintenance > Task Management. Step 2 In the Task Management window, select Task Type in the navigation tree. Step 3 Select one or more scheduled tasks in the task list in the right pane. Step 4 Click Delete. Step 5 In the Confirm dialog box, click Yes. Then the task is deleted from the task list. ----End
8.7.6 Browsing the Information of Timing Tasks

On the M2000, you can browse information about timing tasks such as the task name, user name, process, and execution result according to your own permissions.
Prerequisite
l l
You have logged in to the M2000 client. At least one timing task exists.
Procedure
Step 1 Choose Maintenance > Task Management. Step 2 In the Task Management window, select Task Type in the navigation tree.
NOTE
l l l
The task list area on the right displays the information about the tasks that can be viewed by the current user. If you want to view the common parameters and extended parameters of each task, go to Step 3 Part of periodic tasks support the function of downloading the log file of task execution results from the server. The downloaded log file is saved to the client. Thus, the user can view the history execution results of periodic tasks at any time: 1. Select the tasks that support log file download, and then click Save Log. 2. In the Selecting the Logs to Be Saved dialog box, select the log file to be saved, and then click OK. 3. In the Select Folder dialog box, select the path for saving the log file, and then click Select.
Issue 03 (2010-08-31)
8-45
Step 3 Double click a task, or select a task and click Attribute. The Attribute dialog box is displayed. In the Common Parameter tab and Extended Parameter tab, you can view the task details.
NOTE
l l
If State of a task is Finished, you can view the task information only. If State of a task is Idle, Suspend, or Running, you can modify the task details in the Attribute dialog box.
----End
8.7.7 Viewing the Task Execution

You can view the last execution results of a timing task.
Prerequisite
l l
Context
l
During the creation of CME tasks, sub-tasks are created, which are executed in different phases. You can browse the execution progress of subtasks of CME tasks.
Procedure
l
View the execution conditions in the Prev Execution Result column in the task list in the right pane. You can check the result details in the Result Information area.
----End
8.7.8 Viewing the Task History

You can view the last execution history of a timing task.
Prerequisite
l l
Context
l
During the creation of CME tasks, sub-tasks are created, which are executed in different phases. You can browse the execution progress of sub-tasks of CME tasks.
8-46
Procedure
l l
Select any task displayed on the right pane. Right click on the selected task and select View History to view the history information.
NOTE
Only 100 history records can be displayed on the View History Information window.
----End
8.7.9 Downloading Task Execution Tasks

You can download the execution file of NodeB license allocation tasks to a local PC and then check the specific resource allocation information.
Prerequisite
l l
You have logged in to the M2000 client. NodeB license allocation tasks are available in the system.
Procedure
Step 1 Choose Maintenance > Task Management. The Task Management window is displayed. Step 2 In the navigation tree, choose Task Type > Other > NodeB License Timed Distribution. Step 3 In the task list on the right, right-click a task, and then choose Download Task File from the shortcut menu to download the license resource allocation file set in the task to a local PC. ----End
8.7.10 Downloading Result Files

This describes how to download the results of timing tasks. You can save the results of timing tasks on the server to the local client in .txt format.
Prerequisite
l l
You have logged in to the M2000 client. The timing task that is used for downloading the result files exists and it is run for at least once.
Context
The allowable operations vary depending on the task type, as shown in Table 8-11.
Issue 03 (2010-08-31)
8-47
Table 8-11 Allowable operations for different task types Task Type CME , iSStar Script Executor or Pre-alarm Handling task Allowable Operation The task result are saved on the server in logs. The Result Info area displays only the information about the last task execution. The result logs are not displayed. You can download all the result files to the local client. Result files of multiple tasks can be downloaded concurrently. MML Script task Health Check task Dual Home Management task Timing task, NE Software Download task, and NE Backup task You can download the latest result file to the local client. Result files of multiple tasks can be downloaded concurrently. You can download the result file of the selected task. Result files of multiple tasks can be downloaded concurrently. You can view the latest consistency check result on line. If a task is performed at least once, you can save the messages in the Result Info area to a local path.
Procedure
Step 1 Choose Maintenance > Task Management. The Task Management window is displayed. Step 2 In the navigation tree, select the type of the task that is used to download the result files. Select the specific tasks in the right pane. Step 3 Perform the following operations according to the task type. Task Type CME, iSStar Script Executor or Prealarm Handling task Procedure To download the result logs of a download task, perform the following steps: 1. Select the task whose result logs you plan to download. 2. Click Save Log. In the displayed Please select a directory dialog box, set the save path 3. Click OK.
NOTE The system generates a folder for the log file generated each time and saves the folder to the specified path. The result log file is named in the format YYYY-MMDD_HH-MM-SS, for example, 2008-04-18_10-27-53.
8-48
Issue 03 (2010-08-31)
Task Type MML Script task
Procedure To download the result files of a single task, do as follows: 1. Select the MML script task whose result files you plan to download. 2. Right-click a task and choose Save MML Result on the shortcut menu. Alternatively, you can right-click the Result Info field and choose Save AS on the shortcut menu. 3. Set the save path in the displayed Save dialog box, and then click Save. To download the result files of multiple tasks, do as follows: 1. Press Ctrl or Shift to select multiple MML script tasks in the task list. 2. Right-click the tasks and choose Save MML Result on the shortcut menu. 3. Set the save path in the displayed Save dialog box, and then click Save. Save the execution results of multiple MML script tasks to the same file.
OMC Check or Alarm Check task
1. Select the task whose result files you plan to download. 2. Right-click a task and choose NHC Report on the shortcut menu. 3. In the displayed NHC Report dialog box, select the check report based on Report Nameand then click Save.
NOTE You can click Open to view the contents of the check report and decide whether the report needs to be downloaded.
4. Set the save path in the displayed Please select a directory dialog box. 5. Click OK. Dual Home Management task Right-click a task and choose Checked Result from the shortcut menu.
NOTE If data inconsistency exists, you need to generate a script to adjust the data difference and synchronize the data.
Issue 03 (2010-08-31)
8-49
Task Type Timing task, NE Software Download task, and NE Backup task
Procedure To download the result information about a download task, perform the following steps: 1. Select a task whose result information needs to be downloaded. 2. Right-click in the Result Info area can choose Save As from the shortcut menu. 3. Set the save path in the displayed Save dialog box, and then click Save.
----End
8.8 Reference of the OSS Management GUI

This part describes the OSS management interfaces and related information such as the parameters used in the OSS management. This helps you understand the functions of OSS management easily. 8.8.1 Interface Description: Managing Scheduled Tasks This section describes the Task Management window and relevant parameters. You can refer to this part when performing related operations. 8.8.2 Interface Description: M2000 Log Information Collector When the log information collector on the M2000 client or server is faulty, you can collect all related log files through FTP from the M2000 client or server to locate faults. 8.8.3 Parameters for the NE Partitioning Information This section describes the related parameters in the Query NE Subarea dialog box. You can refer to the these parameters when you check the NE partitioning information. 8.8.4 Parameters for Querying the M2000 License This section describes the parameters in the License Information dialog box. You can refer to these parameters when you view M2000 licenses information. 8.8.5 Parameters for Setting Monitoring Parameters of the M2000 Server This topic describes the parameters of system monitor settings. You can use these parameters when you set the server thresholds. 8.8.6 Parameters for Monitoring the M2000 Server Service Status This topic describes the parameters of the query result displayed in the Service Monitor tab. You can use these parameters when you monitor the M2000 server service status 8.8.7 Parameters for Monitoring the M2000 Server Process Status This topic describes the parameters of the query result displayed in the Process Monitor tab. You can use these parameters when you monitor the M2000 server process status. 8.8.8 Parameters for Monitoring the M2000 Server Hard Disk Status This topic describes the parameters of the query result displayed in the Hard Disk Monitor tab. You can use these parameters when you monitor the M2000 server hard disk status. 8.8.9 Parameters for Monitoring the M2000 Server Database Status
This topic describes the parameters of the query result displayed in the Database Monitor tab. You can use these parameters when you monitor the M2000 server database status. 8.8.10 Parameters for Monitoring the M2000 Server Status This topic describes the parameters of the query result displayed in the Server Monitor tab. You can use these parameters when you monitoring the M2000 server status. 8.8.11 Parameters for Viewing the Information about M2000 Server Components This topic describes the parameters on the Component Information tab page. You can use these parameters when you view the information about M2000 server components. 8.8.12 Parameters for Setting Task Filter Conditions This topic describes the parameters in the Filter Task dialog box. When you set filter conditions for a task list, you can refer to this topic. 8.8.13 Parameters for Setting the Common Information for Creating or Replicating a Task This topic describes the parameters on the common information panel in the New Task or Copy Task dialog box. When you create or copy a task, you can refer to this topic. 8.8.14 Parameters for Setting Common Parameters for Timing Tasks This topic describes the parameters on the Common Parameters tab on property panels of all timing tasks except the CME loading task. When you modify a timing task, you can refer to this topic. 8.8.15 Parameters for Setting the Time When a Periodic Task Is Created or Copied This topic describes the time parameters in the New Task or Copy Task dialog box. When you set the time of a periodic task, you can refer to this topic. 8.8.16 Parameters for Setting the Time When a One-Time Task Is Created or Copied This topic describes the time parameter in the New Task Copy Task dialog box. When you modify the time of a one-time task, you can refer to this topic. 8.8.17 Parameters for Modifying a Database Capacity Management Task This section describes the parameters of database capacity management tasks. You can refer to this part and set relevant parameters when modifying a database capacity management task. 8.8.18 Parameters for Modifying the Export of Performance Data This section describes the parameters for exporting performance data, which can be your reference during the parameter modification. 8.8.19 Parameters for Modifying a Configuration Data Export Task This section describes the parameters of NIC Configuration Data Export and Configuration Data Export tasks. You can refer to this part when modifying parameters. 8.8.20 Parameters for Modifying the Export of NE Logs This section describes the parameters for exporting NE logs and can be taken as reference during the parameter modification. 8.8.21 Parameters for Modifying the Export of Inventory Data This section describes the parameters for exporting inventory data, which can be your reference during the parameter modification. 8.8.22 Parameters for Modifying an Alarm/Event Log Export Task This describes the parameters for modifying an alarm/event log export task. 8.8.23 Parameters for Modifying the Export of M2000 Logs This describes the parameters for exporting M2000 logs and can be taken as reference during the parameter modification.
8.8.24 Parameters for Modifying NE Basic Information Export Task This section describes the parameters involved in the NE basic information export task. When modifying an NE basic information export task, you can refer to this part and perform relevant operations. 8.8.25 Parameters for Modifying the Synchronization of NE Configuration Data This section describes parameters used for synchronization of NE configuration data. When modifying the parameters, you can set the parameters by referring to the information described in this section. 8.8.26 Parameters for Modifying the Synchronization of Inventory Data This section describes parameters used for synchronization of inventory data. When modifying the parameters, you can set the parameters by referring to the information described in this section. 8.8.27 Parameter Description: Modifying a Data Backup Task of the M2000 This section describes the parameters related to data backup tasks of the M2000. You can refer to the description when modifying a data backup task. 8.8.28 Parameters for Creating/Modifying/Copying NE Backup This section describes the parameters related to NE backup tasks. You can refer to this part when creating or modifying NE backup tasks. 8.8.29 Parameters for Creating/Modifying/Copying MML Command Script This section describes the parameters of MML command script tasks. When creating or modifying MML command script tasks, you can refer to this part. 8.8.30 Parameters for Creating, Modifying, or Copying a Configuration Report Export Task This topic describes the parameters involved in the export of RAN reports, CN resource reports, NE reports, NE statistic reports, and NE link reports. When creating, modifying, or copying an export task of these reports, you can refer to this topic and perform relevant operations. 8.8.31 Parameter Description: Creating, Viewing, or Modifying a Scheduled Report Task This section describes the parameters for setting a scheduled report task. You can refer to the description in this section when creating, querying, or modifying a scheduled task. 8.8.32 Parameters for Creating/Modifying/Copying Scheduled NodeB License Allocation Tasks This section describes the parameters of scheduled NodeB license allocation tasks. You can refer to this section when creating or modifying scheduled NodeB license allocation tasks. 8.8.33 Parameters for Creating/Modifying/Copying Scheduled BSC or RNC License Allocation Tasks This section describes the parameters of scheduled BSC or RNC license allocation tasks. You can refer to this section when creating or modifying scheduled BSC or RNC license allocation tasks. 8.8.34 Parameters for Creating/Modifying/Copying a Task for Testing BTS Cabinet-Top Power This section describes the parameters of a task for testing BTS cabinet-top power. You can refer to this section when creating or modifying such a task. 8.8.35 Parameters for Creating/Modifying/Copying an RSSI Test Task This section describes the parameters of an RSSI test task. You can refer to this section when creating or modifying an RSSI test task. 8.8.36 Parameters for Creating/Modifying/Copying Software Download This section describes the parameters in the software download task. When creating or modifying software download task, you can set the parameters for software download task by referring the information described in this section.
8.8.37 Parameters for Creating/Modifying/Copying a Dual-Homing Auto Consistency Check Task This section describes the parameters for creating, modifying, or copying a dual-homing auto consistency check task. 8.8.38 Parameters for Creating/Modifying/Copying an HSL Script Task This section describes the parameters of HSL script tasks. You can refer to this part and set relevant parameters when creating or modifying an HSL script task. 8.8.39 Parameters for Creating/Modifying/Copying the Export of NE Upgrade Log This describes the parameters for exporting NE logs and can be taken as reference during the parameter modification. 8.8.40 Parameters for Creating/Modifying/Copying a CME Upload Task This describes the parameters of a CME upload task. When creating or modifying a CME upload task, you can refer to the parameter description and perform relevant operations. 8.8.41 Parameters for Creating/Modifying/Copying Cell Parameters Compare Task This describes the parameters involved in the CME cell algorithm comparison task. When creating or modifying a CME cell algorithm comparison task, you can refer to this part and perform relevant operations. 8.8.42 Parameters for Creating/Modifying/Copying Cell Consistency Check Task This describes the parameters involved in the CME cell consistency check task. When creating or modifying a CME cell consistency check task, you can refer to this part and perform relevant operations. 8.8.43 Parameters for Creating/Modifying/Copying a CME Current Area Export Task This describes the parameters of CME Current Area Export tasks. When creating or modifying a CME Current Area Export task, you can refer to the information described in this part. 8.8.44 Parameters for Setting Time of Timing Tasks This section describes the parameters of time for automatic suspending and automatic resuming timing tasks 8.8.45 Parameters for Selecting Objects for OMC Check This part describes the extended parameters for selecting objects for OMC check. You can refer to this part when creating device check tasks. 8.8.46 Parameters for Collecting NM Logs Parameters This describes the parameters of the M2000 log information collecting tool dialog box. When collecting NMS log files, refer to the information described here for parameter setting.
8.8.1 Interface Description: Managing Scheduled Tasks

This section describes the Task Management window and relevant parameters. You can refer to this part when performing related operations. After you log in to the server, the Task Management window is displayed, as shown in Figure 8-8. For the description of Figure 8-8, see Table 8-12.
Issue 03 (2010-08-31)
8-53
Figure 8-8 Task Management window
Table 8-12 Description of the Task Management window No. (1) (2) Name Navigation tree Task result information panel Description You can locate the object of a scheduled task through the navigation tree. After a task is completed, the task result is displayed on the task result information panel. You can browse through the result of the latest task on the panel. Only the result of the currently selected task is displayed on the panel. If multiple tasks are selected in the task list, the result of only the firstly selected task is displayed. The buttons used for performing central task management are available on the button panel. You can browse through the scheduled tasks existing on the server and their details. In the task list, different colors indicate different task statuses. Gray: complete; Orange: suspended; Blue: active; White: idle. After you select a task in the list, the color of the task becomes darker than before.
(3)
Button panel
(4)
Task list
8-54
Issue 03 (2010-08-31)
8.8.2 Interface Description: M2000 Log Information Collector

When the log information collector on the M2000 client or server is faulty, you can collect all related log files through FTP from the M2000 client or server to locate faults. The Log Information Collector interface contains four parts:
l
Server Information: In this area, you can set Server Address, Port, FTP User Name, and Password. Items Selection: In this area, you can select the required information. To collect the client trace files, server trace files, or server core files, you must set Start Time and End Time of a specific time segment. To collect the alarm location information, enter an NE name in NE Name. Directory: This area shows the path for saving the diagnosis information. You can change the path. Collected Information Details: In this area, you can view the information collection process and progress.
Figure 8-9 shows the interface. Figure 8-9 M2000 Log Information Collector interface
8.8.3 Parameters for the NE Partitioning Information

This section describes the related parameters in the Query NE Subarea dialog box. You can refer to the these parameters when you check the NE partitioning information.
Issue 03 (2010-08-31)
8-55
Parameter Description
Parameter Query Condition NE Subarea Description Host Name of the NE Partitioning When you query the specific partitioning information, you can select names of all partitions or the name of a specific partition from the dropdown list. indicates the NE Name. indicates the serial number of the NE. indicates the NE Name. indicates the version of the NE. indicates the number of the NEs that belong to the NE Partitioning. indicates the partitioning information about the NE, including the IP address and the instance name of the database.
NE Name Query Result No. NE Name NE Version Number of NEs Statistic
8.8.4 Parameters for Querying the M2000 License

This section describes the parameters in the License Information dialog box. You can refer to these parameters when you view M2000 licenses information.
Parameters
Parameter Find Description Description: Find the matched license item after you enter a license name and then click .
NOTE If a matched record is found, the row of the record is displayed and automatically selected.
Resource Control Item
Resource
Description: Names of authorization items.
License Capacity
Description: Capacity defined in the license.
License Consumption
Description: Capacity of the licenses consumed.
8-56
Issue 03 (2010-08-31)
Parameter Time of License Consumption Overflow Detailed Information
Description Description: Expiry time of each authorization item. Description: View details of authorization items. Server ID Description: Local server ID and authorization server ID displayed after you click Server ID Update License Description: Click the button to update license. Export License Description: Export a license to a file on the local client for future maintenance and browse.
Function Control Item
Function
Description: Names of authorization items.
Supported or Not
Description: Whether a function supports license control.
8.8.5 Parameters for Setting Monitoring Parameters of the M2000 Server

This topic describes the parameters of system monitor settings. You can use these parameters when you set the server thresholds.
Issue 03 (2010-08-31)
8-57
Parameters
l
8-58
Issue 03 (2010-08-31)
l
Issue 03 (2010-08-31)
8-59
l
l l l l

l l l l
8-60
Issue 03 (2010-08-31)
l
Settings Value:
l
Table 8-15 Database Monitor Name Database Monitor Parameter Settings Database status refresh interval (300-3600 seconds) Description Description: Interval of database refreshing. Settings Value: Value range: 300-3600 Default value: 300
Issue 03 (2010-08-31)
8-61
l

l l l l
8-62
Issue 03 (2010-08-31)
l
l

Table 8-16 Service Monitor Name Services Monitor Parameter Settings Service status refresh interval (60-3600 seconds) Description Description: Interval of service refreshing. Settings Value: Value range: 60-3600 Default value: 60
Issue 03 (2010-08-31)
8-63
l if a monitored

l You can double-
8.8.6 Parameters for Monitoring the M2000 Server Service Status

This topic describes the parameters of the query result displayed in the Service Monitor tab. You can use these parameters when you monitor the M2000 server service status
Parameters
Name Service Name Description Description: The name of a service. Process Name Description: The name of a process. Description Description: The description information of functions and interfaces provided by a service. Status Description: The status of a service.
8-64
Issue 03 (2010-08-31)
Name Startup Mode
Description Description: The service start mode, including Automatic, Manual, and Disable. The Disable mode is available only for stopped services.
Start Time
Description: The time that the service is started.
Server Name
Description: The name of the server.
8.8.7 Parameters for Monitoring the M2000 Server Process Status

This topic describes the parameters of the query result displayed in the Process Monitor tab. You can use these parameters when you monitor the M2000 server process status.
Parameters
Name Process Name Description Description: Name of a process. Process ID Description: ID of a process. Handle Count Description: Number of handles used by a process. CPU Usage(%) Description: CPU usage of a process. Memory Usage(MB) Description: Sum of the virtual and physical memory usage of a process. DB Connection Number Description: Number of database connections used by a process. This parameter is displayed when the database is the Sybase database. Thread Number Description: Number of threads generated by a process.
Issue 03 (2010-08-31)
8-65
8.8.8 Parameters for Monitoring the M2000 Server Hard Disk Status
This topic describes the parameters of the query result displayed in the Hard Disk Monitor tab. You can use these parameters when you monitor the M2000 server hard disk status.
Parameters
Name File System Description Description: Hard disk partitions and their paths. Total Size (MB) Description: Total space of a specific partition, equals to the sum of Used Size and Free Size. Used Size (MB) Description: Used space of a specific partition. Free Size (MB) Description: Available space of a specific partition. Usage (%) Description: Current usage of a specific partition. Status Description: Current status of a specific partition, including normal and abnormal. If the usage is more than or equal to the maximum, the system displays Abnormal.
8.8.9 Parameters for Monitoring the M2000 Server Database Status

This topic describes the parameters of the query result displayed in the Database Monitor tab. You can use these parameters when you monitor the M2000 server database status.
Parameters
Name Database Name Description Description: Name of the database on the M2000 server. Total Data Space (MB) Description: Total data space. Free Data Space (MB) Description: Remaining data space.
8-66
Issue 03 (2010-08-31)
Name Data Space Usage (%)
Description Description: Usage rate of the used data space and total data space. This parameter is displayed when the database is the Sybase database.
Total Log Space (MB)
Description: It refers to the space allocated to each database log of the M2000. This parameter is not displayed when the database is the Oracle database.
Free Log Space (MB)
Description: It refers to the unused disk space allocated to database logs. This parameter is displayed when the database is the Sybase database.
Log Space Usage (%)
Description: It is calculated by the following formula: Log Used Rate = (Total Log Space - Free Log Space)/Total Log Space x 100%. This parameter is displayed when the database is the Sybase database.
Total Data Space Usage (%)
Description: Usage rate of the used database storage space and total database space. This parameter is displayed when the database is the Oracle database.
Table Space Usage (%)
Description: Usage rate of the used table space of the database and total table space. This parameter is displayed when the database is the Oracle database.
Status
Description: Database status, including normal and abnormal. If the database usage is more than or equal to the threshold, the system displays Abnormal.
8.8.10 Parameters for Monitoring the M2000 Server Status

This topic describes the parameters of the query result displayed in the Server Monitor tab. You can use these parameters when you monitoring the M2000 server status.
Issue 03 (2010-08-31)
8-67
Parameters
Name Server Name Description Description: Name of the M2000 server. Server Status Description: Status of the M2000 server, including Active, Slave and Standby. OS Description: Operating system of the server. Total Physical Memory (MB) Description: Total physical memory space. Free Physical Memory (MB) Description: Remaining physical memory space. Total Swap Memory (MB) Description: Total virtual memory space. Free Swap Memory (MB) Description: Remaining virtual memory space. CPU Usage (%) Description: CPU usage. Memory Usage (%) Description: The usage of the total memory space (including physical memory and virtual memory).
8.8.11 Parameters for Viewing the Information about M2000 Server Components
This topic describes the parameters on the Component Information tab page. You can use these parameters when you view the information about M2000 server components.
Parameters
Name Component Description Description: Component name of the M2000 server. Version Description: Component version of the M2000 server.
8-68
Issue 03 (2010-08-31)
Name Description
Description Description: Component description of the M2000 server.
8.8.12 Parameters for Setting Task Filter Conditions

This topic describes the parameters in the Filter Task dialog box. When you set filter conditions for a task list, you can refer to this topic.
Parameters
Parameter User Name Current User Description Description: Indicates the user that operates the client. Other Users Description: Indicates other users except the current user. Catego ry User Task Description: Indicates the task created by users. System Task Description: Indicates the task created by OMC during the system installation or upgrade. State Idle Description: Indicates that the task waits for being performed by the system. Running Description: Indicates that the task is being performed by the system. Suspend Description: The task is not ready to be scheduled. Finished Description: Indicates that the task is completed by the system. Archived Description: The archived state is supported only by the CME download task. After the CME download task is stopped, the task is archived. Only when the task is in the archived state, the task can be deleted. Last Run Result Success Description: Indicates that the task is successfully carried out. Processing Description: Indicates that the task is being processed by the system.
Issue 03 (2010-08-31)
8-69
Parameter Partly Success Failed
Description Description: Indicates that the task is partly successfully carried out. Description: Indicates that the task fails to carry out.
Miss Run Time
Description: Indicates that the task misses the previous performed time. If the server is not running properly or the task is suspended before the execution, the task may miss the previous execution. Description: Indicates that the previous execution result in the server is lost caused by improper service or sudden power cut. Thus, after recovery, the previous execution result cannot be determined.
Unknown
8.8.13 Parameters for Setting the Common Information for Creating or Replicating a Task
This topic describes the parameters on the common information panel in the New Task or Copy Task dialog box. When you create or copy a task, you can refer to this topic.
Parameters
Name Task Name Description Description: Refers to the name of a timing task. Settings Value:
l
This parameter allows a maximum of 60 characters. This parameter is exclusive and cannot be empty. These characters are case sensitive.
Task Type
Description: Refers to the task type of a timing task.
Setting method: In the Task Type navigation tree, select the task to be created. -
Run Type
Once
Description: Select this check box and the system runs the tasks that you create only once at the special time.
8-70
Issue 03 (2010-08-31)
Name Period
Description Description: Select this check box and the system runs the tasks that you create periodically.
Settings -
8.8.14 Parameters for Setting Common Parameters for Timing Tasks

This topic describes the parameters on the Common Parameters tab on property panels of all timing tasks except the CME loading task. When you modify a timing task, you can refer to this topic.
Parameters
Parameter Task Name Description Description: Refers to the name of a timing task Value Range Value:
l
A maximum of 60 characters Unique and not null Case sensitive
l l
Run Type
Once
Description: If you select this option, the system runs the created task once at the defined time point.
Period
Description: If you select this option, the system runs the created task periodically.
Start time
Description: This parameter sets the time for starting a task. The start time should be later than the time displayed on the server.
Value: If you have selected Run At Once, the Start Time parameter is invalid. The task is performed immediately after the related settings are complete.
Issue 03 (2010-08-31)
8-71
Parameter No. of period
Description Description: Interval between periodic tasks. It has two enlistments: unit and duration.
Value Range Value:

l
The period can be represented in either of the following units: minutes, hours, days, weeks, months. The period, however, cannot be represented in seconds. The supported units of Period vary according to the task type. The value range for period should be as follows: Minute (1366 x 24 x 60), Hour (1 - 366 x 24), Day (1 - 366), Week (1 - 52), Month (1 - 12).
No. of run times
Description: This parameter indicates the times that a periodic task is executed.
Value: 0-65535
NOTE
l 0 indicates that the
number of times for executing periodic tasks is not restricted.

l This parameter is
displayed in the Attribute dialog box only after you set it when creating and copying a periodic task.
End time
Description: End time of a periodic task.
Value: Later than Start time, and earlier than 12/31/2038 23:59:59.
NOTE This parameter is displayed in the Attribute dialog box only after you set it when creating and copying a periodic task.
8-72
Issue 03 (2010-08-31)
8.8.15 Parameters for Setting the Time When a Periodic Task Is Created or Copied
This topic describes the time parameters in the New Task or Copy Task dialog box. When you set the time of a periodic task, you can refer to this topic.
Parameters
Parameter Time Setting Start time Description Description: Start time of a periodic task. Settings Setting method: You can set this parameter with the following two methods:
l
Enter the time in time textbox (you can also use the spin button to adjust the time).
Click to select the date and time in the Date/Time Selection dialog box.
DST
Description: This parameter indicates whether time use DST. This parameter is configurable only when the current time is DST.
Period Setting
No. of period
Description: Interval of periodic tasks. The value consists of numerals and units.
Value:
l
The period can be represented in either of the following units: minutes, hours, days, weeks, months. The period, however, cannot be represented in seconds. The supported units of Period vary according to the task type. The value range for period should be as follows: Minute (1366 x 24 x 60), Hour (1 - 366 x 24), Day (1 366), Week (1 - 52), Month (1 - 12).
Issue 03 (2010-08-31)
8-73
Parameter No. of run times
Description Description: Number of times for executing periodic tasks.
Settings Value: 0 - 65535

NOTE 0 indicates that the number of times for executing periodic tasks is not restricted.
End time
Description: End time of a periodic task.
Setting method: You can set this parameter with the following two methods:
l
Enter the time in time textbox (you can also use the spin button to adjust the time).
to select the Click date and time in the Date/Time Selection dialog box.
Value: Later than Start time and earlier than 12/31/2038 23:59:59.
8.8.16 Parameters for Setting the Time When a One-Time Task Is Created or Copied
This topic describes the time parameter in the New Task Copy Task dialog box. When you modify the time of a one-time task, you can refer to this topic.
8-74
Issue 03 (2010-08-31)
Parameters
Name Time Setting Description Description: Start time of a one-time task. Settings Setting method: You can set the time with the following two methods:
l
Enter the time in Start Time (you can also use the spin button to adjust the time).
Click to select the date and time in the Date/Time Selection dialog box.
NOTE If the Run At Once check box is selected, the task is performed immediately after you set the parameters.
DST
Description: This parameter indicates whether time use DST. This parameter is configurable only when the current time is DST.
8.8.17 Parameters for Modifying a Database Capacity Management Task

This section describes the parameters of database capacity management tasks. You can refer to this part and set relevant parameters when modifying a database capacity management task.
l l l l
Parameters of Alarm/Event Log Dump Tasks Parameters of Performance Data Tasks Parameters of NE Log Tasks Parameters of NM Log Dump Tasks
Table 8-17 Parameters of Alarm/Event Log Dump Tasks Parameter File compression after export Value Range Selected from the drop-down list Description When the data in the database expires, the system can choose whether to compress files after the export. You can select either Yes or No in this field. Yes is selected by default.
Issue 03 (2010-08-31)
8-75
Parameter File type
Value Range Selected from the drop-down list
Description Refers to the format of the file that saves the exported data. Alarm database capacity management tasks support .txt, .csv, .html, and .xml files. Refers to the path for saving exported data. The save path is specified by the server and cannot be modified. Alarm/event log dump tasks: / export/home/omc/var/ThresholdExport/ FM. Refers to the storage duration of data in the database. The default storage duration is 90 days. Refers to the upper threshold of the file dump space. When you export files, the earliest dumped files are replaced if the total size of the files in the specified path exceeds the preset upper threshold.
NOTE When setting the upper threshold of dump space, you need to task the space of the partition to which the save path of files belongs into consideration. The set upper threshold cannot exceed the size of the partition.
File path
None.
Storage period in database File size
Unit: day Value range: 1-90 Unit: MB Default value: 1,024 Value range: 200-2048
File Storage period
Unit: day Default value: 15 Value range: 3-30
Refers to the storage duration of dumped files. The system automatically deletes the files whose storage duration exceeds the preset days. Refers to the upper threshold of the files in the file dump space. When you export files, the earliest dumped files are replaced if the total number of the files in the specified path exceeds the preset upper threshold.
File count
Number of files Default value: 1,000 Value range: 200-2000
Table 8-18 Parameters of Performance Data Tasks Parameter Export Data Value Range Selected from the drop-down list Description If you select Yes, the system automatically deletes the expired performance data, and the parameters related to file export become invalid. If you select No, the system exports the expired performance data according to the preset file export parameters.
8-76
Issue 03 (2010-08-31)
Parameter Compress File After Export
Value Range Selected from the drop-down list
Description When the data in the database expires, the system can choose whether to compress files after the export. You can select either Yes or No in this field. Yes is selected by default. Refers to the format of the file that saves the exported data. Performance database capacity management tasks support .csv files. Refers to the path for saving exported data. The save path is specified by the server and cannot be modified. Performance database capacity management tasks: /export/home/omc/var/ ThresholdExport/PM. Refers to the storage duration of data in the database. The default storage duration is 30 days. Refers to the upper threshold of the file dump space. When you export files, the earliest dumped files are replaced if the total size of the files in the specified path exceeds the preset upper threshold.
File Format
Selected from the drop-down list None.
Save File Path
Hold Days in the Database File Size
File Hold Days
l
File Sum
Hold Days Setting
Select Common Mode or Configuration Mode.
Common Mode: You need to manually enter a value in Hold Days in the Database. The value range is 1-90. The default value is 30. Configuration Mode: You need to specify Configuration File. The system uses the storage duration specified in the configuration file.
Issue 03 (2010-08-31)
8-77
Table 8-19 Parameters of NE Log Tasks Parameter Compress File After Export Value Range Selected from the drop-down list Description When the data in the database expires, the system can choose whether to compress files after the export. You can select either Yes or No in this field. Yes is selected by default. Refers to the format of the file that saves the exported data. NE log database capacity tasks support .txt and .csv files. Refers to the path for saving exported data. The save path is specified by the server and cannot be modified. NE log database capacity management tasks: /export/home/omc/var/ ThresholdExport/NeLog. Refers to the storage duration of data in the database. The default storage duration is 30 days. Refers to the upper threshold of the file dump space. When you export files, the earliest dumped files are replaced if the total size of the files in the specified path exceeds the preset upper threshold.
File Format
Selected from the drop-down list None.
Save File Path
Hold Days in the Database File Size
File Hold Days
File Sum
Table 8-20 Parameters of NM Log Dump Tasks Parameter File compression after export Value Range Selected from the drop-down list Description When the data in the database expires, the system can choose whether to compress files after the export. You can select either Yes or No in this field. Yes is selected by default.
Issue 03 (2010-08-31)
8-78
Parameter File type
Value Range Selected from the drop-down list Default path: /opt/ OMC/var/ ThresholdExport/ Log Unit: day Value range: 1-90
l
Description Refers to the format of the file that saves the exported data. M2000 log database capacity management tasks support .xml and .csv files. Refers to the path for saving exported data.
File path
Storage period in database (days) Export File Management
Refers to the storage duration of data in the database. The default storage duration is 30 days.
l
Unit: day. Value range: 3-30. Default value: 15 Unit: file. Value range: 200-1000. Default value: 1000 Unit: M. Value range: 200-2048. Default value: 1024
Only hold XX Day(s): In the dump directory, the log files older than this period are deleted. Only hold XX File(s): In the dump directory, if the number of log files exceeds the value of this parameter, the M2000 deletes the oldest dump files until the number of log files in this directory becomes less than the value of this parameter. Only hold XX M of file: In the dump directory, if the total size of log files exceeds the value of this parameter, the M2000 deletes the oldest dump files until the total size of log files in this directory becomes less than the value of this parameter.
8.8.18 Parameters for Modifying the Export of Performance Data

This section describes the parameters for exporting performance data, which can be your reference during the parameter modification. Table 8-21 lists the extended parameters. Table 8-21 Description of extended parameters Parameter File Format Value Range You can choose:
l l l
Description Performance measurement results are exported as a .csv or .xml file.
CSV. XML. TXT.
Hold Days
Enter as required. The default value is 7.
The data of a task is deleted from the server after the storage duration expires.
8-79
Issue 03 (2010-08-31)
Parameter File Path
Value Range Default value. No change. The default path is /export/ home/omc/var/fileint/pm/.
Description By default, the exported data is saved in the /export/home/omc/ var/fileint/pm/ path. The default value cannot be changed. You can set the measurement period for an export task by clicking different measurement period tabs. This parameter is used to set the execution period of an export task. The available values of this parameter depend on the selected NE type.
NOTE The export period and measurement period of performance data must be consistent.
Period
You can click different measurement period tabs.
Export Period
Options in the drop-down list.
Delay Time
The value must be multiples of 5 minutes. Value range: 51440. The unit is minute.
The parameter specifies the delay time for running a task. The value must be an integral multiple of 5 minutes and should not be null. You can control the function subset navigation tree in the left pane by selecting Show Been Set Measuring Function Subsets and Show All Function Subsets. In the navigation tree in the left pane, you can select the function subset whose performance measurement results are to be exported and then click or to add the function subset to the area on the right so that the performance measurement results of the selected function subset can be periodically exported according to the task settings.
Function Subsets
You can select function subsets from the navigation tree.
8-80
Issue 03 (2010-08-31)
Parameter Template
Value Range You can select templates from the navigation tree.
Description After a result query template is selected, query results are periodically exported according to the settings of the template.
CAUTION If the result query templates having the same name exist on one measurement period tab page, and if the performance measurement results are to be exported by template name according to the setting in the configuration file of the tool for exporting performance measurement results collected by the M2000, the result files that are exported on the basis of the templates sharing the same name will replace each other when you select a template sharing the same name with other templates. To avoid file replacement, you need to change the names of the result query templates or modify the setting in the configuration file so that performance measurement results are exported by template ID.
Filter Search
None
The system searches for results by the name of a function subset. The searching condition is case insensitive. In addition, the fuzzy search is supported, whereas the wildcard search is not supported.
8.8.19 Parameters for Modifying a Configuration Data Export Task

This section describes the parameters of NIC Configuration Data Export and Configuration Data Export tasks. You can refer to this part when modifying parameters.
For details about the extended parameters of NIC Configuration Data Export tasks, see Table 8-22.
Issue 03 (2010-08-31)
8-81
Table 8-22 Extended parameters of NIC Configuration Data Export tasks Parameter Export Path Value Range Default value. No change. The default path is /export/home/ omc/var/fileint/ cm/GExport. File Save Time Default value. No change. The default storage duration is 3 days. File Need Compressed Default value. No change. The default value is Yes. Export NEs You need to select NEs in the navigation tree according to the actual requirement. Determines whether to decompress the exported configuration data files before saving them on the M2000 server. Refers to the storage duration of the exported configuration data files on the M2000 server. Description Refers to the path for saving the exported configuration data files on the M2000 server.
Export All NE: The M2000 will export the configuration data of all NEs. Export By NE Type: After you select the required NE type, the M2000 will export the configuration data of all the NEs of this type. Export By NE: After you select the required NEs, the M2000 will export the configuration data of all the selected NEs.
For details about the extended parameters of Configuration Data Export tasks, see Table 8-23. Table 8-23 Extended parameters of Configuration Data Export tasks Parameter File Format Value Range Two formats (.xml and .csv) are available in the drop-down list. You need to select either of them. Description Refers to the file format in which the exported data is saved.
8-82
Issue 03 (2010-08-31)
Parameter File Path
Value Range Default value. No change. The default path is /export/home/ omc/var/fileint/ cm/autoExport.
Description Refers to the path for saving the exported configuration data.
Please Select NE
You need to select NEs in the Physical Topology Tree navigation tree. If All NE Configuration Data is selected, the Physical Topology Tree navigation tree becomes unavailable, and the M2000 will export the configuration data of all NEs.
l l l
: to expand all subnodes. : to collapse all subnodes. : indicates a cascading selection. That is, after you select a certain parent node, all its subnodes are selected accordingly.
8.8.20 Parameters for Modifying the Export of NE Logs

This section describes the parameters for exporting NE logs and can be taken as reference during the parameter modification. Table 8-24 lists the extended parameters. Table 8-24 Descriptions of extended parameters Parameter File Format File Path Value Range You can select .txt or .csv. Default value: No change. The default path is: /export/ home/omc/var/fileint/nelogs/. Description Exports the operation logs to a .txt file or .csv file. Saves NE logs.
Issue 03 (2010-08-31)
8-83
Parameter File Size
Value Range Unit: MB Default value: 1024
Description Refers to the threshold of the space for dumping log files. During the export of log files, if the size of the files existing in the specified path exceeds the preset threshold, the earliest files are replaced.
NOTE When setting the threshold of dump space, the size of the partition that the path for saving log files belongs to must be taken into account. The threshold cannot exceed the size of the partition.
File Hold Days
Unit: day Default value: 15
Refers to the number of the days within which the dump files can be saved. After these days, the files are automatically deleted. Refers to the maximum number of files in the dump space. During the export of log files, if the number of the files existing in the specified path exceeds the preset threshold, the earliest files are replaced.
File Sum
Number of files Default value: 1000
8.8.21 Parameters for Modifying the Export of Inventory Data

This section describes the parameters for exporting inventory data, which can be your reference during the parameter modification.
Parameter File Format Description Refers to the format in which the exported data files are saved. Three formats are available, that is, .XML, .CSV and .TXT. You can select from the drop-down list. Indicates the path to save the exported inventory data. Default value: /export/home/omc/var/fileint/cm/InvtTimerExport. All NE Please Select NE If you select this option, the system exports the inventory data of all NEs on the network. This option is selected by default. Indicates all the NEs in the entire network. Multiple NEs are supported. You can select the specific NEs in Please Select NE only after you deselect All NE.
File Path
8-84
Issue 03 (2010-08-31)
8.8.22 Parameters for Modifying an Alarm/Event Log Export Task

This describes the parameters for modifying an alarm/event log export task. Table 8-25 describes the extended parameters for modifying an alarm/event log export task. Table 8-25 Extended parameters Parameter File type Value Range You can select the following file types:
l l l l
Description The exported file is in .CSV , .TXT, .HTML or .XML format.
CSV. XML. TXT. HTML.
Compression format
You can select one of the following items.

l l l
Not compress zip gzip

l
If you select zip or gzip, it indicates that the .csv, .xml, .txt or .html files are decompressed and then exported. If you select Not compress, it indicates that the .csv, .xml file, .txt or .html is exported.
Export To
The default value is used and cannot be changed. The default path is /export/ home/omc/var/fileint/fm/.
The save path of exported alarm/ event log.
File prefix
The value contains 0-30 characters.
Prefix of export file names. Export files are named in the export path in the format of prefix-export time-data type. For example, assume that the prefix is abc. The generated file names are abc-20090928104022-alarmlog-auto-1.zip and abc-20090928104022-event-logauto-1.zip.
Issue 03 (2010-08-31)
8-85
Parameter Alarm Severity, Category, and Type
Value Range You can select the following values:

l
Description Select the severity, category, and type of the alarm to be exported.
Alarm severities: Critical, Major, Minor, and Warning. Alarm Categories: Alarm Log and Event Log. Type: Power system, Environment system, Signaling system, Trunk system, Hardware system, Software system, Running system, Communication system, QoS, Processing error, Internal, Integrity violation, Operational violation, Physical violation, Security service or mechanism and Time domain violation. List the alarms that can be exported currently.
Alarm Name
You can select alarm names.
8.8.23 Parameters for Modifying the Export of M2000 Logs

This describes the parameters for exporting M2000 logs and can be taken as reference during the parameter modification. Table 8-26 lists the extended parameters. Table 8-26 Descriptions of extended parameters Parameter File compression after export Value Range
l l
Description
l
Yes. No.
If you select Yes, the .csv files or .xml files are compressed to a packet and exported. If you select No, the .csv files or .xml files are directly exported.
Export File Type File path
You can select .csv or .xml. The default path is:/export/ home/omc/var/fileint/ ***logs/, where *** stands for the log type.
Exports operation logs to a .csv file or .xml file. Saves the exported logs.
8-86
Issue 03 (2010-08-31)
Parameter Export File Management
Value Range
l
Description
l
Unit: day. Value range: 3-30. Default value: 15 Unit: file. Value range: 200-1000. Default value: 1000 Unit: M. Value range: 200-2048. Default value: 1024
Only hold XX Day(s): In the export directory, the log files older than this period are deleted. Only hold XX File(s): In the export directory, if the number of log files exceeds the value of this parameter, the M2000 deletes the oldest export files until the number of log files in this directory becomes less than the value of this parameter. Only hold XX M of file: In the export directory, if the total size of log files exceeds the value of this parameter, the M2000 deletes the oldest export files until the total size of log files in this directory becomes less than the value of this parameter.
8.8.24 Parameters for Modifying NE Basic Information Export Task

This section describes the parameters involved in the NE basic information export task. When modifying an NE basic information export task, you can refer to this part and perform relevant operations.
Parameter description
The M2000 provides the function of exporting NE basic information. Thus, it can provide data to the Nastar for performance analysis. You can modify the common parameters and extended parameters of the task according to the actual requirement. Parameter Exported File Description Export the file containing NE basic information to the /export/home/omc/var/fileint/network/ EAMInfo.xml path on the M2000 server. The NE navigation tree is unavailable. You need not specify the NEs to be exported. The M2000 exports the information about all NEs. After you select a certain NE type from the NE navigation tree, the M2000 exports the information about all NEs of this type.
Export All NE
Export By NE Type
Issue 03 (2010-08-31)
8-87
Parameter Export By NE
Description After you select some NEs from the NE navigation tree, the M2000 exports the information about all selected NEs.
8.8.25 Parameters for Modifying the Synchronization of NE Configuration Data

This section describes parameters used for synchronization of NE configuration data. When modifying the parameters, you can set the parameters by referring to the information described in this section.
Parameter All NE Configuration Data Please Select NE Description If All NE Configuration Data is selected, the system synchronizes the configuration data of all existing NEs in the network. Select existing NEs in the entire network. Multiple NEs are supported.
8.8.26 Parameters for Modifying the Synchronization of Inventory Data

This section describes parameters used for synchronization of inventory data. When modifying the parameters, you can set the parameters by referring to the information described in this section.
Parameter All NE Please Select NE Description If you select this option, the system synchronizes the inventory data of all NEs on the network. Indicates all the NEs in the entire network. Multiple NEs are supported. You can select the specific NEs in Please Select NE only after you clear All NE.
8-88
Issue 03 (2010-08-31)
8.8.27 Parameter Description: Modifying a Data Backup Task of the M2000

This section describes the parameters related to data backup tasks of the M2000. You can refer to the description when modifying a data backup task. For description of the extended parameters, see Table 8-27. Table 8-27 Extended Parameters Parameter Server Full Backup Date Value Range Monday to Sunday Description The full backup is performed once a week. For example, if this parameter is set to Monday, the full backup is performed every Monday. Path for saving the backup data of the M2000.
Backup File Path
The default path is recommended and cannot be changed. The default path is / export/home/ backup/omc.
8.8.28 Parameters for Creating/Modifying/Copying NE Backup

This section describes the parameters related to NE backup tasks. You can refer to this part when creating or modifying NE backup tasks.
Parameter File Path Backup All NE Description Refers to the path to save NE data backup files. It is specified by the system. If you select this parameter, the system backs up the data of all NEs available in the current network. By default, the system backs up the data of all NEs in the entire network.
Issue 03 (2010-08-31)
8-89
Parameter By NE Type
Description If this option is selected, you should specify the NE type in the NE Type navigation tree. 1. Select By NE Type. The By NE Type dialog box is displayed. 2. In the navigation tree in the left pane, select one or multiple NE types. 3. Click side. Click side.
NOTE
l Click
to add the selected NE types to the valid domain at the right to add the all NE types to the valid domain at the right
to delete the selected NE types from the valid domain at the right to delete the all NE types from the valid domain at the right
side. Click side.

l Click
and
to collapse and expand nodes in the navigation tree. to filter nodes in the
l Enter filtering conditions in Name, and then click
navigation tree.
4. Click Apply. By NE If this option is selected, you should specify the NE in the NE navigation tree. 1. Select By NE. The By NE dialog box is displayed. 2. In the navigation tree in the left pane, select one or multiple NEs. 3. Click Click
NOTE
l Click
to add the selected NEs to the valid domain at the right side. to add the all NEs to the valid domain at the right side.
to delete the selected NEs from the valid domain at the right side. to delete the all NEs from the valid domain at the right side. and to collapse and expand nodes in the navigation tree. to filter nodes in the
Click
l Click
l Enter filtering conditions in Name, and then click
navigation tree.
4. Click Apply.
8.8.29 Parameters for Creating/Modifying/Copying MML Command Script

This section describes the parameters of MML command script tasks. When creating or modifying MML command script tasks, you can refer to this part.
8-90
Issue 03 (2010-08-31)
Parameter Script file Value Range The script file is in .txt format. The maximum size is 2 MB. None. Description The MML script file is a text file that records MML commands for one NE or multiple NEs of the same type. You can click , and then select the MML script file in the displayed Open dialog box. After you select this option, you can change the NE of a script command by selecting the NE in the NE tree instead of modifying the script file. After the NE is selected, the original NE information in the script file is invalid, and all the commands are issued to the newly selected NE. The NE tree displays all the NEs in a physical topology tree. The function buttons for selecting NEs are described as follows:
l l l
Select NE
: You can click this button to expand the NE tree. : You can click this button to collapse the NE tree. : You can click this button to use the Single Select mode. That is, if you select a node, the subnodes are not selected. You can click this button to switch to the Recursive Select mode. : to use the Recursive Select mode. That is, if you select a node, the subnodes are also selected. You can click this button to switch to the Single Select mode.
NOTE When creating MML script tasks, you must select Select NE to choose NE objects if certain command lines in the script file does not contain object information.
Execution Mode
Parallel or Serial.
Two modes for issuing MML commands are available:

l
Parallel: indicates that the MML commands are issued to the NE concurrently. Serial: indicates that the MML commands are issued to the NE in sequence.
Error-Execute Mode
Ignore or Stop.
Refers to the mode of handling the errors that occur when you run the MML commands in the MML script file.
l
Ignore: ignores the MML commands where errors occur and continues running other MML commands. Stop: stops running other MML commands.
Issue 03 (2010-08-31)
8-91
Execution Result
None.
If the type of a created task is Once, you can select Save As and specify the path for adding the execution result of the task to a certain redirection file. If the specified redirection file does not exist, you can create the file. If the specified redirection file exists, the new information written into the file does not overwrite the original information. If you have set task result redirection, the path specified in Save As cannot be changed after a task is created.
8.8.30 Parameters for Creating, Modifying, or Copying a Configuration Report Export Task
This topic describes the parameters involved in the export of RAN reports, CN resource reports, NE reports, NE statistic reports, and NE link reports. When creating, modifying, or copying an export task of these reports, you can refer to this topic and perform relevant operations.
On the M2000, you can set an export task on the configuration reports that you are concerned to export the configuration reports of a specified NE to a specified directory on the server. Parameter File Path Description Refers to the path for saving a report. The path cannot be changed. The default path is /export/home/omc/var/fileint/cm/ Report. NE Type In the case of RAN reports, you can choose any one of MBTS, WCDMA, CDMA, GSM as the NE type.
TIP
l In the case of NEs of the WCDMA, CDMA, or GSM
type, you also need to select the NEs whose reports are to be exported from the NE navigation tree after selecting the NE type.
l In the case of NEs of the MBTS type, you need not select
the specific NEs. The M2000 automatically exports all the MBTS reports to the specified path.
In the case of NE link reports, you can select any one of SGSN, RNC, MSCServer, BSC6000(R11+), BSC6810(R11+), BSC6900GSM, BSC6900UMTS, and BSC6900GU as the NE type. Selected Report Type You can select Selected to specify Report Type.
8-92
Issue 03 (2010-08-31)
8.8.31 Parameter Description: Creating, Viewing, or Modifying a Scheduled Report Task

This section describes the parameters for setting a scheduled report task. You can refer to the description in this section when creating, querying, or modifying a scheduled task.
Common Parameters
Parameter Basic informatio n Task Name Description Indicates the name of a scheduled report task. Value range:
l l
A maximum of 64 characters The following characters except the apostrophe character (') are allowed: English characters, Chinese characters, numbers or other special characters. That is, the apostrophe character (') is not allowed. The value must be unique and cannot be null.
Start Time
Indicates the time when a task starts to be executed. You can click and set the related parameters in the displayed Date/Time Selection dialog box. The start time must be later than the current time of the server.
Run Type
Indicates the execution type of a scheduled report task. Value range:

l
Periodic, which indicates that the system performs a created task periodically. Once, which indicates that the system performs a created task once in a specific time. If you select this option, the parameters in the Execution Period become unavailable.
Execution Period
Indicates the interval between periodic tasks. An interval has two dimensions: unit and duration. The unit of the period can be hour, day, week, or month.
Execution Times
Indicates the number of times that a periodic task is executed. Value range:
l
Unlimited, which indicates that the periodic task is executed for an unlimited number of times. Limited, which indicates that the periodic task is executed for N times. N is a specific number.
Issue 03 (2010-08-31)
8-93
Extended Parameters
Parameter Extended parameter Report Name Save Path Description Indicates the name of a scheduled report task. Indicates the path for saving the report. For example: /report/$ReportOwner$/$TaskName$$Date $. For details about each field, see Table 8-28. File Name Indicates the format of the report name. For example: $reportname$-$date$. For details about each field, see Table 8-28. File Format Indicates the format of the report file. Value range:
l l l
Excel HTML CSV
Compress File
Indicates whether to compress the scheduled report files. Value range:

l l
Selected Deselected
Compress File is selected by default. The format of the compressed file is .zip. Maximum File Number Indicates that the report files of a periodic task generated for the recent N times are saved on the system. N is a specific number. Value range:
l
Unlimited, which indicates that all the report files of the periodic task are saved on the system. Limited, which indicates that the report files of the periodic task generated for the recent N times are saved on the system.
Table 8-28 lists the predefined macros that are supported by the save path and file name. Table 8-28 Predefined macros Predefined Macro $ReportOwner$ $TaskType$ Meaning Indicates the creator of a report. Indicates the type of a periodic task. Value range: once, hour, weekly, monthly.
8-94
Issue 03 (2010-08-31)
Predefined Macro $Time$ $DateTime$ $Format$ $TaskOwner$ $ReportName$ $TaskName$ $Date$ $Index$ $yy$
Meaning Indicates the time when a periodic report is generated. Indicates the date and time when a periodic report is generated. Indicates the format of a periodic report. Indicates the creator of a scheduled report task. Indicates the name of a report. Indicates the name of a scheduled task. Indicates the date when a periodic report is generated. Indicates the number of times that a scheduled task is executed. Year Indicates a year, which supports the simple expression. For example, $yy-1$ indicates the year preceding the current year, and $yy+1$ indicates the year following the current year.
$mm$
Month Indicates a month, which supports the simple expression. For example, $mm-1$ indicates the month preceding the current month, and $mm+1$ indicates the month following the current month.
$dd$
Day Indicates a day, which supports the simple expression. For example, $dd-1$ indicates the date preceding the current date, and $dd+1$ indicates the date following the current date.
$hh$
Hour Indicates an hour, which supports the simple expression. For example, $hh-1$ indicates the hour preceding the current hour, and $hh+1$ indicates the hour following the current hour.
Issue 03 (2010-08-31)
8-95
Predefined Macro $Moh$
Meaning Minute Indicates a minute, which supports the simple expression. For example, $Moh-1$ indicates the time that is one minute earlier than the current time, and $Moh+1$ indicates the time that is one minute later than the current time.
NOTE
The rules for naming the scheduled report files are as follows:
l l
A performance report file in the .xls format is named by the value of File name. A performance report file in the .html or .csv format is named by File name+Subreport name. For example, in the name task_120080523151900report_1, task_120080523151900 is named according to a user-defined rule and report_1 is the subreport name.
Distribution Parameters
Parameter Email Distributio n To: Description Indicates the recipient of emails. Use commas to separate recipient names. Click Email Boxes. The Select the distributing email box dialog box is displayed. Select one or more mailboxes and then click OK.
TIP You can right-click any record and then choose Select All or Clear All from the shortcut menu to quickly select or clear all the records.
The system can send scheduled report files to a maximum of 64 email recipients simultaneously. Email Subject Indicates the subject of an email. If you have set email recipients in To, you must set the subject. Email Contents FTP Distributio n FTP Server Indicates the contents of an email. Indicates the IP address of the server. Click FTP Server. The Select the distributing FTP server dialog box is displayed. Select one or more servers and then click OK.
The system can send scheduled report files to a maximum of eight FTP servers simultaneously.
8-96
Issue 03 (2010-08-31)
Parameter SMS Distributio n Telephone
Description Indicates the number of the SMS recipient. Click SMS Recipient. The Select SMS Recipient Number dialog box is displayed. Select one or more SMS recipient numbers and then click OK.
You can add or delete SMS recipient numbers. When you modify an SMS recipient number, only the remarks can be modified. The SMS recipient number can only be set to a digit string. Rows in SMS Indicates the maximum number of lines in an SMS sent to the SMS recipient. Value range: 1 to 5. Counters in SMS Indicates the maximum number of KPIs included in an SMS sent to the SMS recipient. Value range: 1 to 4. Append Time Indicates whether to include the time information in the SMS. If this option is selected, it indicates that the time information is included in the SMS. Append Object Indicates whether to include the object information in the SMS. If this option is selected, it indicates that the object information is included in the SMS.
NOTE
The system adopts a redistribution mechanism. That is, in the case of an email, SMS, or FTP distribution failure, the system immediately redistributes the email, SMS, or FTP information. A maximum of three redistributions are provided. In addition, you can manually run a scheduled report task as required. Then, the PRS generates a report file at the task execution time, and then distributes the generated report files to an email recipient, SMS recipient, or an FTP server.
8.8.32 Parameters for Creating/Modifying/Copying Scheduled NodeB License Allocation Tasks

This section describes the parameters of scheduled NodeB license allocation tasks. You can refer to this section when creating or modifying scheduled NodeB license allocation tasks.
Issue 03 (2010-08-31)
8-97
Parameter Task File Description
l
To create a scheduled NodeB license allocation task by allocating a license to NEs on a scheduled basis The system automatically generates a .csv license resource allocation file based on the preset license allocation information and displays the file in Task File. Manual export is not required. To create a scheduled NodeB license allocation task by creating a user timing task Click Import, and then select the NodeB license resource allocation file to be allocated. You can export NodeB license allocation information through Exporting the Assignment Information About NodeB Common Licenses in the RAN Subnet and then change the allocation data of the NodeB common license.
CAUTION When modifying the license allocation information, you need to ensure that the exported file is intact. That is, the information such as NE information, telecom operator information, and control item information cannot be deleted. You need to modify only the license allocation information.
NOTE
l For details about how to download the task file, see 8.7.9
Downloading Task Execution Tasks.
NE
In the NE navigation tree, select the NE where the license allocation file is to be used. Only one scheduled allocation task can be created for an NE. The NEs for which tasks are created are not displayed in the NE navigation tree any longer. The task names corresponding to these NEs are displayed in the Existed Task Information list.
8.8.33 Parameters for Creating/Modifying/Copying Scheduled BSC or RNC License Allocation Tasks
This section describes the parameters of scheduled BSC or RNC license allocation tasks. You can refer to this section when creating or modifying scheduled BSC or RNC license allocation tasks.
8-98
Issue 03 (2010-08-31)
Parameter NE Description Select an NE for which you need to download the license file from the NE navigation tree. Only one scheduled allocation task can be created for one NE. The NEs for which tasks are created are no longer displayed in the NE navigation tree. The task names corresponding to these NEs are displayed in the Created NE Task Information. License file Select a BSC or an RNC license file to be downloaded from the drop-down list.
NOTE This drop-down list displays all the NE license files that are uploaded to the M2000. For details about how to upload a license file, see Uploading an NE License to the Server.
8.8.34 Parameters for Creating/Modifying/Copying a Task for Testing BTS Cabinet-Top Power
This section describes the parameters of a task for testing BTS cabinet-top power. You can refer to this section when creating or modifying such a task.
NOTE
The portals of the Top Power Test task are as follows:

l l
Maintenance > Task Management. Maintenance > RF Performance Test > Top Power Test.
Parameter Execution Duration NE
Value Range 3-120 minutes None
Description Maximum execution duration of a task Existing NE that supports cabinet-top power test.
8.8.35 Parameters for Creating/Modifying/Copying an RSSI Test Task

This section describes the parameters of an RSSI test task. You can refer to this section when creating or modifying an RSSI test task.
Issue 03 (2010-08-31)
8-99
NOTE
The portals of the RSST Test task are as follows:

l l
Maintenance > Task Management. Maintenance > RF Performance Test > RSSI Test.
Parameter Execution Duration NE Frequency
Value Range 3-120 minutes None 0-2047 The default value is null, which indicates that all frequencies are tested.
Description Maximum execution duration of a task Existing NE that supports RSSI test. Frequency to be tested in an RSSI task.
8.8.36 Parameters for Creating/Modifying/Copying Software Download

This section describes the parameters in the software download task. When creating or modifying software download task, you can set the parameters for software download task by referring the information described in this section.
Parameter NE Type Edition List Value Range Select the value from the drop-down list. None. Description Indicates all of the NE types available in the current network. Indicates the editions of all NEs that can be downloaded from the server. These NEs are of the same type. Multiple choices are not allowed. Indicates all of the NEs of an NE type available in the current network. Multiple choices are supported.
NE List
None.
8.8.37 Parameters for Creating/Modifying/Copying a Dual-Homing Auto Consistency Check Task

This section describes the parameters for creating, modifying, or copying a dual-homing auto consistency check task.
8-100
Issue 03 (2010-08-31)
Parameter Dual Homing Pairs Description Indicates the dual-homing pairs whose data is to be checked. Indicates the data resource type of the dual-homing pairs to be checked. Data resource types vary according to the version of the dual-homing pair NE. Setting -
Resource Type
Select the corresponding item in the Resource Type navigation tree. Type a data resource type or keyword in Search. Then the related resource types are listed in the area under Search. You can double-click a resource type to be checked.
Search
Is used to search for the type of the data resource to be checked. Case-insensitive search rather than wildcard search is supported.
Type a data resource type or keyword in Search.
8.8.38 Parameters for Creating/Modifying/Copying an HSL Script Task

This section describes the parameters of HSL script tasks. You can refer to this part and set relevant parameters when creating or modifying an HSL script task.
Parameter Main File Value Range The main file is in .hsl format. The maximum size of the main file is 1 MB. The maximum size of the assistant file is 1 MB. None. Description The main file is the entry file for the execution of a script.
Assistant File
During the execution of a script, the main file can select scripts that need to be invoked from assistant files. You need to specify NEs if the script will be executed on certain NEs. You can select multiple NEs.
NE Selection
Issue 03 (2010-08-31)
8-101
8.8.39 Parameters for Creating/Modifying/Copying the Export of NE Upgrade Log

This describes the parameters for exporting NE logs and can be taken as reference during the parameter modification. Table 8-29 lists the extended parameters. Table 8-29 Description of extended parameters Parameter Please Select NE Start Time Value Range None. The start time must meet the requirement of time format. Description Refers to all the NEs on the entire network. All NE upgrade logs within the time range specified by the start time and end time are to be queried. All NE upgrade logs within the time range specified by the start time and end time are to be queried. Operation logs are exported to .xml files. Refers to the path for saving NE logs.
End Time
The end time must meet the requirement of time format.
File Format File Path
The default file format must be retained. The default file path must be retained. The default path is /export/ home/omc/var/field/ UpgradeHistory/.
8.8.40 Parameters for Creating/Modifying/Copying a CME Upload Task

This describes the parameters of a CME upload task. When creating or modifying a CME upload task, you can refer to the parameter description and perform relevant operations.
Parameter All NE Description After you select this option, the system uploads the configuration data of all the NEs that support CME tasks on the network. The NEs that support CME tasks are the RNC, NodeB, BSC6000, BSC6900 GSM, BSC6900 UMTS and BSC6900 GU. After you select this option, the system uploads the configuration data of all the NodeBs under the selected RNCs.
Issue 03 (2010-08-31)
All NodeBs Under RNC

8-102
Parameter Please Select NE
Description Indicates the NEs of all the existing RNCs and NodeBs in the entire network. Multiple NEs are supported. You can select the specific NEs in Please Select NE only after you clear All NE.
8.8.41 Parameters for Creating/Modifying/Copying Cell Parameters Compare Task

This describes the parameters involved in the CME cell algorithm comparison task. When creating or modifying a CME cell algorithm comparison task, you can refer to this part and perform relevant operations. A CME cell algorithm comparison task can be performed to compare the parameters in the Current area with the default parameters in the CME configuration template and then export the comparison results to the specified path. Parameter Cell Input Mode Select the NE of a Cell Description After you select this mode, you can specify the NEs of a cell whose parameters are to be compared. After you select this mode, you can import the list of cells whose parameters are to be compared. Select the name of the controller managing the cell. The M2000 automatically compares the parameters of all the cells managed by the selected controller. Select the template to be compared. The M2000 automatically compares the cell parameters with the default configuration parameters of the selected template. For example, you can select Default 2G Cell Template.
Import Cell
Select the NE of a Cell and the Template
NE
Template
8.8.42 Parameters for Creating/Modifying/Copying Cell Consistency Check Task

This describes the parameters involved in the CME cell consistency check task. When creating or modifying a CME cell consistency check task, you can refer to this part and perform relevant operations.
Issue 03 (2010-08-31)
8-103
A cell consistency check task can be performed to check that the data in the Current area complies with the selected check rules. Parameter NE Description Select the name of the controller managing the cell. The M2000 automatically compares the parameters of all the cells managed by the selected controller. Select check rules.
Rule
8.8.43 Parameters for Creating/Modifying/Copying a CME Current Area Export Task

This describes the parameters of CME Current Area Export tasks. When creating or modifying a CME Current Area Export task, you can refer to the information described in this part.
To manage the current data area, you can perform a CME data export task to export the data from the current data area for Northbound. Parameter Select Export Type Description Select the data to be exported and its file format. The parameter values are as follows:
l
XML format:

radio parameter transmission parameter radio and transmission parameter radio parameter transmission parameter radio and transmission paramete
CSV format:

Select NE
Select one or multiple controllers of the cell to which the data to be exported belongs. If you select All NEs, the data in the current data areas under all the controllers is to be exported.
8.8.44 Parameters for Setting Time of Timing Tasks

This section describes the parameters of time for automatic suspending and automatic resuming timing tasks
Table 8-30 lists the parameters of auto-suspend time and auto-resume time for timing tasks. Table 8-30 Descriptions of parameters for setting timing task time Parameter Suspend Time Description The system suspends an idle task and delay the time for using this task. If the timing task is not in the Idle state at the specified time, it fails to be suspended. You can set the value manually. Alternatively, you can click
l l l l l l
and select the time from the time select panel.
The time format is DD/MM/YYYY HH:MM:SS. YYYY stands for the year. MM stands for the month. DD stands for the date. HH stands for the hour. MM stands for the minute. SS stands for the second.
Resume Time
In the specified time, the system resume a suspended task and then the task is in the idle state and wait to be dispatched. If the timing task is not in the Idle state at the specified time, it fails to be suspended. You can set the value manually. Alternatively, you can click
l l l l l l
and select the time from the time select panel.
The time format is DD/MM/YYYY HH:MM:SS. YYYY stands for the year. MM stands for the month. DD stands for the date. HH stands for the hour. MM stands for the minute. SS stands for the second.
8.8.45 Parameters for Selecting Objects for OMC Check

This part describes the extended parameters for selecting objects for OMC check. You can refer to this part when creating device check tasks.
Parameter Device Check NE
Issue 03 (2010-08-31)
Description OMC OMC

Parameter Health Check
Description Sun Server:Displays the health check items supported by M2000.

l l l l l l
Operating System Sybase VERITAS Volume Manager Software Sun Cluster Host Hardware OMC
HP or ATAE Server:Displays the health check items supported by M2000.

l l l l l l
Operating System Oracle VERITAS Volume Manager Software VCS Cluster S3X00 Array OMC
8.8.46 Parameters for Collecting NM Logs Parameters

This describes the parameters of the M2000 log information collecting tool dialog box. When collecting NMS log files, refer to the information described here for parameter setting.
Parameter Server informatio n Server address Description Complies with the principles of IP address rules. Cannot be null. Port Number Indicates the port of the server. Value range: 1-65,536 The default value is 10119. Cannot be null. FTP User name Indicates a valid name that the user already registered to the M2000. Cannot be null. password Indicates the password that is used to log in to the target server. Cannot be null. Items selection
8-106
Trace files in Local Host
Collects the trace files from the M2000 client.
Issue 03 (2010-08-31)
Parameter Trace files in server Core files in server LMT trace files in server Start Time End Time Alarm diagnostic data NE Name Save Positions Save Positions
Description Collects the trace files from the M2000 server. Collects the core files from the server. Collects the trace files from the local maintenance terminal (LMT). Indicates the start time for collecting trace files and core files. Indicates the end time for collecting trace files and core files. Collects the alarm synchronization signals of NEs. Collects the NEs involved in alarm diagnostic data. Indicates the directory for the collected diagnostic data.
Issue 03 (2010-08-31)
8-107
9 Managing the M2000 Processes and Services (HA)
Managing the M2000 Processes and Services (HA)
About This Chapter

This chapter describes how to manage the processes and services of the M2000 HA system. The management of the processes and services ensures the smooth operation of the M2000 HA system. 9.1 Introduction to M2000 Processes and Services When the M2000 is running, the M2000 server automatically starts the processes related to the M2000 system. Each process provides different services and functions. 9.2 Managing M2000 Services (HA) This section describes how to check, start, and stop the services of the M2000 HA system.
Issue 03 (2010-08-31)
9-1
9.1 Introduction to M2000 Processes and Services

When the M2000 is running, the M2000 server automatically starts the processes related to the M2000 system. Each process provides different services and functions. 9.1.1 3rdTool_agent Process This section describes the 3rdToolService service and dependent services. 9.1.2 adn_agent Process This section describes the services and functions provided by the adn_agent process. 9.1.3 adss_agent Process This section describes the services and functions provided by the adss_agent process. 9.1.4 antenna_agent Process This section describes the services and functions provided by the antenna_agent process. 9.1.5 ce_agent Process This section describes the services and functions provided by the ce_agent process. 9.1.6 cmdc_agent Process This section describes the CmDcService service and dependent services. CmDcService is provided by the cmdc_agent process. 9.1.7 cmengine_agent Process This section describes the services and functions provided by the cmengine_agent process. 9.1.8 cmeserver_agent Process This section describes the services and functions provided by the cmeserver_agent process. 9.1.9 cmexp_agent Process This section describes the service and functions provided by the cmexp_agent process. 9.1.10 cmserver_agent Process This section describes the services and functions provided by the process cmserver_agent. 9.1.11 cnnhc_agent Process This section describes the services and functions provided by the cnnhc_agent process. 9.1.12 corba_agent Process This section describes the services and functions provided by the corba_agent process. 9.1.13 cpm_agent Process This section describes the services and functions provided by the cpm_agent process. 9.1.14 devdoc_agent Process This section describes the DevDocService service provided by the devdoc_agent process. 9.1.15 dsXXXX agent Process This section describes the services and functions provided by the dsXXXX_agent process. 9.1.16 eam_agent Process This section describes the services and functions provided by the eam_agent process. 9.1.17 fars_agent Process This section describes the service and function provided by the fars_agent process. 9.1.18 fmnotify_agent Process
This section describes the services and functions provided by the fmnotify_agent process. 9.1.19 FMPreServiceXXXX_agent Process This section describes the services and functions provided by the FMPreServiceXXXX_agent process. 9.1.20 fnlicense_agent Process This section describes the services and functions provided by the fnlicense_agent process. 9.1.21 glmssyn_agent Process This section describes the services and functions provided by the glmssyn_agent process. 9.1.22 ifms_agent Process This section describes the service and functions provided by the ifms_agent process. 9.1.23 ipqdt_agent Process This section describes the services and functions provided by the ipqdt_agent process. 9.1.24 ipm_agent Process This section describes the services and functions provided by the ipm_agent process. 9.1.25 irp_agent Process This section describes the functions provided by the irp_agent process. 9.1.26 itm_agent Process This section describes the ItmService service and the dependent services by the itm_agent process. 9.1.27 lcsserver_agent Process This section describes the services and functions provided by the lcsserver_agent process. 9.1.28 lic_agent Process This chapter describes the services and functions provided by the process lic_agent. 9.1.29 log_agent Process This section describes the LogService service and dependent services. LogService is provided by the log_agent process. 9.1.30 necomm_agent Process This section describes the services and functions provided by the necomm_agent process. 9.1.31 maintain_agent Process This topic describes the function of the MaintenanceService service, which is provided by the maintain_agent process. 9.1.32 manager_agent Process This section describes the services and functions provided by the manager_agent process. 9.1.33 medXXXX_agent Process This section describes the services and functions provided by the medXXXX_agent process. 9.1.34 nelicense_agent Process This section describes the services and functions provided by the nelicense_agent process. 9.1.35 neuser_agent Process This section describes the NeUserService service. NeUserService is provided by the neuser_agent process. 9.1.36 ngnffs_agent Process This section describes the NGNFullFillService service and dependent services.
9.1.37 ngnnis_agent Process This section describes the NGNNIService service and dependent services. 9.1.38 ngnni112_agent Process This section describes the services and functions provided by the ngnni112_agent process. 9.1.39 ngntestmanage_agent Process This section describes the services and functions provided by the ngntestmanage_agent process. 9.1.40 nhcserver_agent Process This section describes the services and functions provided by the nhcserver_agent process. 9.1.41 nicserver_agent Process This section describes the services and functions provided by the nicserver_agent process. 9.1.42 nimserver_agent Process This section describes the NIMServer service and the dependent service. NIMServer is provided by the nimserver_agent process. 9.1.43 nms_mml_agent Process This section describes the services and functions provided by the process nms_mml_agent. 9.1.44 partition_agent Process This section describes the services and functions provided by the partition_agent process. 9.1.45 pm_agent Process This section describes the services and functions provided by the process pm_agent. 9.1.46 pmexp_agent Process This section describes the services and functions provided by the process pmexp_agent. 9.1.47 pmmon_agent Process This section describes the services and functions provided by the process pmmon_agent. 9.1.48 pmncdXX01_agent Process This section describes the services and functions provided by the pmncdXX01_agent process. 9.1.49 porttrunk_agent Process This section describes the services and functions provided by the porttrunk_agent process. 9.1.50 proxy_agent Process This section describes the services and functions provided by the proxy_agent process. 9.1.51 PRSAssistantService_agent Process This section describes the services and functions provided by the PRSAssistantService_agent process. 9.1.52 prsdc_agent Process This section describes the services and functions provided by the prsdc_agent process. 9.1.53 prsfs_agent Process This section describes the services and functions provided by the prsfs_agent process. 9.1.54 prsreport_agent Process This section describes the services and functions provided by the prsreport_agent process. 9.1.55 prssum_agent Process This section describes the services and functions provided by the prssum_agent process. 9.1.56 rn_agent Process This section describes the services and functions provided by the rn_agent process.
9.1.57 ScriptModuleService_agent Process This section describes the services and functions provided by the ScriptModuleService_agent process. 9.1.58 scriptserver_agent Process This section describes the services and functions provided by the process scriptserver_agent. 9.1.59 sm_agent Process This section describes the services and functions provided by the process sm_agent. 9.1.60 snmp_agent Process This section describes the SnmpAgent service and the dependent services. The SnmpAgent service is provided by the snmp_agent process. 9.1.61 son_agent Process This section describes the services and functions provided by the son_agent process. 9.1.62 swm_agent Process This section describes the services and functions provided by the swm_agent process. 9.1.63 threshold_agent Process This topic describes the function of the ThresholdService service provided by the threshold_agent process and the service that the threshold_agent process depends on. 9.1.64 uap_agent Process This section describes the services and functions provided by the uap_agent process. 9.1.65 udpdispatch_agent Process This section describes the services and functions provided by the udpdispatch_agent process. 9.1.66 umgupdsvr_agent Process This section describes the services and functions provided by the umgupdsvr_agent process. 9.1.67 xftpXX01_agent Process This section describes the services and functions provided by the xftpXX01_agent process. 9.1.68 Processes and Services Related to Each Northbound Interface This section describes the processes and services related to each northbound interface. 9.1.69 Checking the Status of the M2000 Processes This section describes how to check the status of the M2000 processes. When the M2000 processes are not running normally, you need to locate faults and log in to the server to rectify the faults in time.
9.1.1 3rdTool_agent Process

This section describes the 3rdToolService service and dependent services. The 3rdTool_agent process provides the 3rdToolService service. The 3rdToolService service provides an interface for the third-party tools to access the data center. Required services: ScriptServer
9.1.2 adn_agent Process

This section describes the services and functions provided by the adn_agent process. The adn_agent process provides the ADNService service.
The ADNService service supports the NodeB plug-and-play function. It provides various functions for newly constructed NodeBs, such as remote automatic activation and automatic fault detection. This helps engineers quickly deploy NodeBs. You can disable the service when it is not required. Required services: PartitionService
9.1.3 adss_agent Process

This section describes the services and functions provided by the adss_agent process. The adss_agent process provides the AdvancedSwitchService service. The AdvancedSwitchService service authenticates the MOI resources to enhance the security of the operations on the NEs, and deepen the security level hiberarchy. During the operation of the M2000, ensure that this service is running properly. Required services: none
9.1.4 antenna_agent Process

This section describes the services and functions provided by the antenna_agent process. The antenna_agent process provides the AntennaTune service. The AntennaTune service provides the functions of managing NodeB antennas and locating the faults related to GBSS antennas. Required service: EAMService.
9.1.5 ce_agent Process

This section describes the services and functions provided by the ce_agent process. The ce_agent process provides the ConfigExport service. The ConfigExport service provides a transparent channel which enables the northbound NMS to directly obtain configuration data and set NE configurations from the GBSS. If this function is required, you must ensure that the service runs normally. Required services: none.
9.1.6 cmdc_agent Process

This section describes the CmDcService service and dependent services. CmDcService is provided by the cmdc_agent process. The cmdc_agent process provides the CmDcService service. The CmDcService service provides the functions such as data access interface, synchronization management, and session management. Required services: TopoAdapterService
9.1.7 cmengine_agent Process

This section describes the services and functions provided by the cmengine_agent process.
The cmserver_agent process provides the CMEngine service. CMEngine manages the configuration of the network manager. Configuration management is independent of NEs or managed objects. When the M2000 is running, ensure that this service functions properly. Required services: TopoAdapterService.
9.1.8 cmeserver_agent Process

This section describes the services and functions provided by the cmeserver_agent process. The cmeserver_agent process provides the CmeServer service. The cmeserver_agent service provides the function of quickly configuring NEs. You can disable the service when it is not required. Required service: none.
9.1.9 cmexp_agent Process

This section describes the service and functions provided by the cmexp_agent process. The cmexp_agent process provides the CMExport service. The CMExport service provides the functions of exporting configuration files and exporting the configuration database. Through the CMExport service, you can set the NE whose configuration data is to be exported, set the save path and file format of the exported data, and export the NE configuration data by using the Management Information Tree (MIT). To enable the functions of exporting configuration files and exporting the northbound database, you need to ensure that this service is running normally. Dependent service: LicenseService.
9.1.10 cmserver_agent Process

This section describes the services and functions provided by the process cmserver_agent. The cmserver_agent process provides the CMServer service. CMserver configures the managed objects of the network manager. Configuration management is independent of NEs or managed objects. The CMServer provides channels for issuing MML commands and helps to receive the supplementary messages reported automatically by NEs. The CMServer provides the function of managing object groups and enables the M2000 to automatically and remotely commission the NodeB upgrade. When the M2000 is running, ensure that this service functions properly. Required services: TopoAdapterService
9.1.11 cnnhc_agent Process

This section describes the services and functions provided by the cnnhc_agent process. The cnnhc_agent process provides the CNNHCService service. CNNHCService provides the functions of information collection and health check. Required service: none.
9.1.12 corba_agent Process

This section describes the services and functions provided by the corba_agent process. The corba_agent process provides the CorbaService service. The CorbaService provides the NBI on which the TMF 814 CORBA protocol runs. Required services: LicenseService, LogService, SecurityService.
9.1.13 cpm_agent Process

This section describes the services and functions provided by the cpm_agent process. The cpm_agent process provides the CPMService service, that is, the pool configuration management service. The Pool configuration management service provides users with the following functions:
l l l l l l l l
Creating a pool Checking pool alarms Measuring the performance of a pool Monitoring the load of a pool in real time Displaying the pool topology Setting pool parameters Checking the NE data in a pool Checking the MSC Server or MSCe of a specific user
Required services: none
9.1.14 devdoc_agent Process

This section describes the DevDocService service provided by the devdoc_agent process. The devdoc_agent process provides the DevDocService service. The DevDocService service enables you to manage device files. Required services: none
9.1.15 dsXXXX agent Process

This section describes the services and functions provided by the dsXXXX_agent process. The dsXXXX_agent process provides the DesktopServiceXXXX service.
Some typical process names are ds0101_agent and ds0102_agent. The corresponding service names are DesktopService0101 and DesktopService0102. dsXXXX_agent is a multi-instance process and XXXX refers to the process number. The DesktopServiceXXXX service presents and operates data on several types of clients such as the Java GUI client and the Web client. You can log in to the client only when the DesktopServiceXXXX service is running properly. During the operation of the M2000, ensure that this service is running properly. Required service: none.
9.1.16 eam_agent Process

This section describes the services and functions provided by the eam_agent process. The eam_agent process provides the EAMService, TopoAdapterService, and TopoService services. The EAMService service provides the function of NE access management and maintains a globally complete NE list. The EAMService service does not depend on any other services. The TopoAdapterService service provides the mediation for earlier versions so that the users who use the earlier versions can use the topology function. The TopoAdapterService service depends on the EAMService, TopoService, LogService, SecurityService, and LicenseService services. The TopoService service can maintain the relation between the devices in the subnet, create and delete subnets, nodes, and topology node, and move nodes among subnets. The TopoService service depends on the EAMService services.
9.1.17 fars_agent Process

This section describes the service and function provided by the fars_agent process. The fars_agent process provides the FarsService. The FarsService provides the function of tracing data collection, data analysis, and data collection management. To enable the tracing function, you need to ensure that the FarsService is running normally during the operation of the M2000. Dependent service: none.
9.1.18 fmnotify_agent Process

This section describes the services and functions provided by the fmnotify_agent process. The fmnotify_agent process provides the FMNotify service. FMNotify forwards the alarm data from FaultManager to the network management system (NMS) by Alarm Streaming Interface. Disable FMNotify when the real-time alarm forwarding function is not required. Required services: LicenseService.
9.1.19 FMPreServiceXXXX_agent Process

This section describes the services and functions provided by the FMPreServiceXXXX_agent process. The FMPreServiceXXXX_agent process provides the FMPreServiceXXXX service. The FMPreServiceXXXX_agent process is a multi-instance process. XXXX refers to the process number. The FMPreServiceXXXX service provides the function of prehandling faults. In the SLS system, you can deploy the FMPreServiceXXXX_agent process on the master node and several slave nodes. You can also deploy multiple FMPreServiceXXXX_agent processes on one node. For example, you can deploy the FMPreService0101_agent, FMPreService0102_agent, and FMPreService0103_agent processes on the master node for providing the FMPreService0101, FMPreService0102, and FMPreService0103 services separately. You can also deploy the FMPreService0201_agent, FMPreService0202_agent, and FMPreService0203_agent processes on a slave node for providing the FMPreService0201, FMPreService0202, and FMPreService0203 services separately. Required service: FaultService.
9.1.20 fnlicense_agent Process

This section describes the services and functions provided by the fnlicense_agent process. The fnlicense_agent process provides the FNLicenseService service. The FNLicenseService provides the fix network management function of managing the license authorization information about EMS. The number of purchased licenses determines the number of available resources and whether the user can use a specific functional component. Required services: LicenseService.
9.1.21 glmssyn_agent Process

This section describes the services and functions provided by the glmssyn_agent process. The glmssyn_agent process provides the GLMSSynService service. The GLMSSynService periodically obtains the information about QChat cluster communication changes from the Group and List Management Server (GLMS) and then applies the information to CBSCs. You can stop this process if the QChat cluster communication is not required. Required services: none.
9.1.22 ifms_agent Process

This section describes the service and functions provided by the ifms_agent process. The ifms_agent process provides the FaultService. The FaultService collects alarm data from NEs and saves the data, thus providing the functions of querying, dumping, and analyzing the fault data. You can disable the service when fault management is not required.
Required service: none.
9.1.23 ipqdt_agent Process

This section describes the services and functions provided by the ipqdt_agent process. The ipqdt_agent process provides the IPQosDailingTest service. IPQosDailingTest tests the IP bearer network to obtain the QoS of the network so as to build a high performance network. The process can be stopped if the QoS dialing test on the IP network is not required. Required services: CMServer and CmDcService
9.1.24 ipm_agent Process

This section describes the services and functions provided by the ipm_agent process. The ipm_agent process provides the IPMService service. The IPMService service enables you to manage an IP network. To use the IP network management function, ensure that the IPMService service is running correctly during the operation of the M2000. Required services: LicenseService.
9.1.25 irp_agent Process

This section describes the functions provided by the irp_agent process.
EPIRP
The EPIRP is subject to the entry point object. The entry point object is the first object that the NMS (Manager) accesses when the NMS interacts with the M2000 (Agent). The Agent provides a reference of an entry point object to the Manager, and the Manager obtains the reference of this entry point object in some way, for example, from the stored file. If the interface for northbound network management is not required, disable the EPIRP. Basic IRP: None.
NotificationIRP
NotificationIRP is used for subscribing to notifications and encapsulating notification subscription. If the function of subscription through the interface of northbound network management is not required, disable the NotificationIRP. Basic IRP: EPIRP.
CSIRP
CSIRP provides an interface for link monitoring. The link monitoring enables you to supervise the status of links between the Manager and the Agent. In this way, the potential exceptions can be detected at the first time. If the function of
monitoring through the interface of northbound network management is not required, disable the CSIRP. Basic IRP: EPIRP, and NotificationIRP.
KernelCMIRP
KernelCMIRP provides an interface for public configuration management. The public configuration management uses KernelCMIRP to carry out some common tasks during the configuration, such as sending configuration objects, or adding, removing and modifying notifications. If the function of public configuration management through the interface of northbound network management is not required, disable the kernelCMIRP. Basic IRP: EPIRP, and NotificationIRP.
BasicCMIRP
BasicCMIRP controls the configuration management. BasicCMIRP is used for querying, modifying, adding, or removing network resource objects. If the function of configuration management through the interface of northband network management is not enabled, disable the BasicCMIRP. Basic IRP: EPIRP, NotificationIRP, FileTransferIRP, and KernelCMIRP.
AlarmIRP
AlarmIRP is used for managing fault data. If the function of fault data management through the interface of northbound network management is not required, disable the AlarmIRP. Basic IRP: EPIRP, NotificationIRP, FileTransferIRP, KernelCMIRP, and BasicCMIRP.
Required Services
The required service is the LicenseService.
9.1.26 itm_agent Process

This section describes the ItmService service and the dependent services by the itm_agent process. The itm_agent process provides the ItmService service. The ItmService service provides the function of integrated task management. Required services: LicenseService
9.1.27 lcsserver_agent Process

This section describes the services and functions provided by the lcsserver_agent process. The lcsserver_agent process provides the LCSServer service. LCSServer provides the function of handling the configuration of LTEs. Through LCSServer, users can edit, maintain, verify, import, and export LTE configuration data. This process can be stopped if the LTE configuration function is not required.
9.1.28 lic_agent Process

This chapter describes the services and functions provided by the process lic_agent. The lic_agent process provides the LicenseService service. LicenseService provides a service interface to validate the license of the current version. Ensure that this service works properly during the M2000 operation. Required services: none
9.1.29 log_agent Process

This section describes the LogService service and dependent services. LogService is provided by the log_agent process. The log_agent process provides the LogService service. The LogService service enables other services to save the system-related operation information to files. It also enables the client to query log records of the operating system and to set and query the parameters for dumping system logs. Required services: none.
9.1.30 necomm_agent Process

This section describes the services and functions provided by the necomm_agent process. The necomm_agent process provides the CommonLicService service and SSLManageService service. The CommonLicService service manages the information about NE license files, such as invalidity, export, and adjustment information. The SSLManageService service manages the SSL connections between the M2000 and NEs. It also manages the SSL certificates used by the SSL connections. During the operation of the M2000, ensure that this service is running properly. Required service: none.
9.1.31 maintain_agent Process

This topic describes the function of the MaintenanceService service, which is provided by the maintain_agent process. The maintain_agent process provides the MaintenanceService service. The MaintenanceService service enables the periodic backup of the important system configuration files, database data, and real-time data of MOs. During the M2000 operation, ensure that the maintain_agent process is operational. Required services: none
9.1.32 manager_agent Process

This section describes the services and functions provided by the manager_agent process. The manager_agent process provides the SystemService service. SystemService enables you to query the M2000 version information such as the version of the operating system, software version of the client, software version of the server, client software version matching the server software, and client upgrade information. Ensure that this service works properly during the M2000 operation. Required services: none
9.1.33 medXXXX_agent Process

This section describes the services and functions provided by the medXXXX_agent process. The medXXXX_agent process provides the MediationServiceXXXX service. The medXXXX_agent is a multi-instance process, and XXXX refers to the instance number. When the M2000 is running, the system dynamically generates new processes and services based on NE types and NE quantity. Some typical process names are med0101_agent, med0102_agent, and med0103_agent, and the names of the corresponding services are MediationService0101, MediationService0102, and MediationService0103. The MediationServiceXXXX service creates, deletes, and obtains the NE engines mirrored to the network devices from the M2000 system and also manages the related event interceptors. NEs of different types communicate with the M2000 system by using the corresponding NE engines through various network management protocols. In addition, the MediationServiceXXXX service can export performance result files on the basis of NEs. During the operation of the M2000, ensure that this service is running properly. Dependent services: none
9.1.34 nelicense_agent Process

This section describes the services and functions provided by the nelicense_agent process. The nelicense_agent process provides the NeLicenseService service. The NeLicenseService service manages NodeB licenses and implements the sharing of a license between the NEs of the same type. Required services: LogService.
9.1.35 neuser_agent Process

This section describes the NeUserService service. NeUserService is provided by the neuser_agent process. The neuser_agent process provides the NeUserService service. The NeUserService service enables you to manage NE users. When the M2000 and NEs are connected properly, you can manage NE users through the M2000. For example, you can authenticate the login of NE users, deliver command rights and command group rights, and customize command groups.
9.1.36 ngnffs_agent Process

This section describes the NGNFullFillService service and dependent services. The ngnffs_agent process provides the NGNFullFillService. The NGNFullFillService service provides functions of the management domain and the subscriber number management. Required services: none
9.1.37 ngnnis_agent Process

This section describes the NGNNIService service and dependent services. The ngnnis_agent process provides the NGNNIService. The NGNNIService service provides functions of the north interface operation management. Required services: none
9.1.38 ngnni112_agent Process

This section describes the services and functions provided by the ngnni112_agent process. The ngnni112_agent process provides the NGNNI112Service service. The NGNNI112Service provides the NBI for the subscriber line test system. Required services: NGNTestManageService.
9.1.39 ngntestmanage_agent Process

This section describes the services and functions provided by the ngntestmanage_agent process. The ngntestmanage_agent process provides the NGNTestManageService service. The NGNTestManageService provides the fix access network test management function. Required services: none.
9.1.40 nhcserver_agent Process

This section describes the services and functions provided by the nhcserver_agent process. The nhcserver_agent process provides the NHCServer service. The NHCServer service provides the NE health check function. The nhcserver_agent process is available only after you have installed the NE health check components. If you plan to perform a heath check task, you must ensure this service is running properly. Required service: ItmService and EAMService.
9.1.41 nicserver_agent Process

This section describes the services and functions provided by the nicserver_agent process.
The nicserver_agent process provides the NICServer service. The NICServer service provides the network information collecting function. The nicserver_agent process is available only after you have installed the network information collecting components. If you plan to perform a network information collecting task, you must ensure this service is running properly. Required service: ItmService and EAMService.
9.1.42 nimserver_agent Process

This section describes the NIMServer service and the dependent service. NIMServer is provided by the nimserver_agent process. The nimserver_agent process provides the NIMServer service. The NIMServer service only enables you to centralize the real-time monitoring of alarms, performance, and configuration status of some WRAN configuration objects. It also only provides the functions to some WRAN configuration objectssuch as alarm statistics, query of basic configuration information, query of configuration link constitution and basic configuration information, and query of adjacent cells and channel assignment. Required services: none
9.1.43 nms_mml_agent Process

This section describes the services and functions provided by the process nms_mml_agent. The nms_mml_agent process provides the NMSMMLServer service. That is, the NMS issues MML commands through the northbound MML transmission interface to managed NEs. If the northbound MML transmission interface is used when the M2000 is running, ensure that the NMSMMLServer is running correctly. When the northbound MML transmission interface is not used, the NMSMMLServer is not disruptive to other services. Required services: LogService.
9.1.44 partition_agent Process

This section describes the services and functions provided by the partition_agent process. The partition_agent process provides the PartitionService service. The PartitionService service divides managed objects into various partitions. Each partition is managed by its own process. In the presence of a large quantity of objects, the partitions are managed by various processes on different servers to balance the load. Ensure that this service works properly during the M2000 operation. Required services: none.
9.1.45 pm_agent Process

This section describes the services and functions provided by the process pm_agent. The pm_agent process provides the PMService service.
PMService monitors performance management on all NEs. The performance management is independent of NEs or objects. Stop PMService if the performance management function is not required. Required services: none.
9.1.46 pmexp_agent Process

This section describes the services and functions provided by the process pmexp_agent. The pmexp_agent process provides the PMExport service. PMExport exports performance data of a measurement unit from the database. PMExport is independent of NEs or managed objects. Stop PMExport when the function of exporting performance results is not required. Required services: LicenseService.
9.1.47 pmmon_agent Process

This section describes the services and functions provided by the process pmmon_agent. The pmmon_agent process provides the PMMonService service. PMMonService monitors key NE counters and displays the value about these counters in figures and tables. Required services: PMService
9.1.48 pmncdXX01_agent Process

This section describes the services and functions provided by the pmncdXX01_agent process. The pmncdXX01_agent process provides the PMNCDServiceXX01 service. The pmncdXX01_agent is a multi-instance process and XX01 refers to the instance number. Generally, the process name is pmncd0101_agent and the name of the corresponding service is PMNCDService0101. By default, the system saves the performance data of the neighboring cells of the RNC and BSC in files. The database does not hold the data. To view the data of the neighboring cells, you need to import the data from the files to the database and then query the results. The PMNCDServiceXX01 service imports the performance data of the neighboring cells from the files to the database. When the M2000 is running, ensure that this service functions properly. Required services: PMService.
9.1.49 porttrunk_agent Process

This section describes the services and functions provided by the porttrunk_agent process. The porttrunk_agent process provides the PortTrunkingService service. By using the PortTrunkingService service, the M2000 server can communicate with the M2000 client through a specified port. You need not configure multiple ports on the firewall for communication.
9.1.50 proxy_agent Process

This section describes the services and functions provided by the proxy_agent process. The proxy_agent process provides the Proxyserver service. Proxyserver enables the M2000 client to connect to NEs through the proxy server and to run applications of the NEs on the LMT . Stop Proxyserver when the proxy function is not required. Required services: none.
9.1.51 PRSAssistantService_agent Process

This section describes the services and functions provided by the PRSAssistantService_agent process. The PRSAssistantService_agent process provides the PRSAssistantService service. The PRSAssistantService service provides the function of generating reports in .html, .csv or .xls format. It also provides the function of transferring result files by email or through the FTP. After restarting the PRSAssistantService service, you need to restart the PRSReportService service. If you need to run the PRS module, the PRSReportService service cannot be stopped. Required services: none
9.1.52 prsdc_agent Process

This section describes the services and functions provided by the prsdc_agent process. The prsdc_agent process provides the PRSDcService service. The PRSDcService service provides the function of obtaining configuration data files and performance data files on schedule. Keep the service running during the operation of the PRS module. Required service: none.
9.1.53 prsfs_agent Process

This section describes the services and functions provided by the prsfs_agent process. The prsfs_agent process provides the PRSFsService service. That is, it provides the service for importing report data. The PRSFsService service provides the function of parsing configuration data files and performance data files on schedule. Keep the service running during the operation of the PRS module. Required service: none.
9.1.54 prsreport_agent Process

This section describes the services and functions provided by the prsreport_agent process. The prsreport_agent process provides the PRSReportService service. The PRSReportService service provides the function of querying the reports of the PRS module. If you need to run the PRS module, the PRSReportService service cannot be stopped. Required services: none
9.1.55 prssum_agent Process

This section describes the services and functions provided by the prssum_agent process. The prssum_agent process provides the PRSSumService service. The PRSSumService service provides the function of summarizing the data of the PRS (Performance Report Suite) module. It is responsible for retrieving data in a specified order and scheduling the data. If you need to run the PRS module, the PRSSumService service cannot be stopped. Required services: CMServer.
9.1.56 rn_agent Process

This section describes the services and functions provided by the rn_agent process. The rn_agent process provides the RNService service. The RNService service provides the user with the function of sending notifications by email or short message. Required service: LicenseService.
9.1.57 ScriptModuleService_agent Process

This section describes the services and functions provided by the ScriptModuleService_agent process. The ScriptModuleService_agent process provides the ScriptModuleService service. The ScriptModuleService service provides the function of managing applications. Required services: ItmService
9.1.58 scriptserver_agent Process

This section describes the services and functions provided by the process scriptserver_agent. The scriptserver_agent process provides the ScriptService service. ScriptService provide script timing and NEs access from script. Ensure that this service works properly during the M2000 operation. Required services: ItmService and SecurityService.
9.1.59 sm_agent Process

This section describes the services and functions provided by the process sm_agent. The sm_agent process provides the SecurityService service. SecurityService controls the access of all sensitive resources in the M2000. Only authorized users can gain access to sensitive resources. Ensure that this service works properly during the M2000 operation. Required services: EAMService and LicenseService
9.1.60 snmp_agent Process

This section describes the SnmpAgent service and the dependent services. The SnmpAgent service is provided by the snmp_agent process. The snmp_agent process provides the SnmpAgent service, that is, the northbound interface service complying with the SNMP protocol. The SnmpAgent service enables the upper-level NMS to obtain the information on the M2000 such as alarm data, through the SNMP protocol. Required services: LogService and LicenseService.
9.1.61 son_agent Process

This section describes the services and functions provided by the son_agent process. The son_agent process provides the SONService service. The SONService service provides a series functions for automatically managing networks, such as automatically detecting, configurating, and optimizing NEs. The DHCP module provides the function of automatically detecting the eNodeB, BWA, pBTS3701, NodeB, GSM Pico, PICO BTS, and TGW. The Easy Deployment System (EDS) module provides the function of automatically creating an LTE site. The Auto Neighbor Relation (ANR) module provides the functions of automatically detecting the neighboring cells of the LTE, querying neighboring cell parameters across cells, and modifying neighboring cell parameters. If the functions for automatically managing networks are not required, this service can be stopped. Required service: none
9.1.62 swm_agent Process

This section describes the services and functions provided by the swm_agent process. The swm_agent process provides the SWMService service. The SWMService manages the versions, configuration data, NE logs, and other files of some NEs. It also provides the download, upload, activation, and rollback functions. Ensure that this service works properly during the M2000 operation. Required services: none
9.1.63 threshold_agent Process

This topic describes the function of the ThresholdService service provided by the threshold_agent process and the service that the threshold_agent process depends on. The threshold_agent process provides the ThresholdService service. The ThresholdService service provides the threshold management function. For example, this service allows you to add, generate, and change a threshold. In addition, this service can generate threshold alarms. During the M2000 operation, ensure that the threshold_agent process is operational. Required services: PMService.
9.1.64 uap_agent Process

This section describes the services and functions provided by the uap_agent process. The uap_agent process provides the UAPService service. The UAPService service provides the Sock5 agent function on the M2000 server. Thus, when users cannot access the BAM server (make sure that the M2000 server normally connects to the BAM), the M2000 client can be started through the agent. The uap_agent process also provides the function of authenticating user operations to meet the requirement of authority and domain based management on the M2000. Required service: none.
9.1.65 udpdispatch_agent Process

This section describes the services and functions provided by the udpdispatch_agent process. The udpdispatch_agent process provides the UdpDispatchService service. The UdpDispatchService service controls the forwarding of the Snmp Trap messages that are reported by NEs monitored by the M2000. The UdpDispatchService service forwards the Snmp Trap messages that are reported to port 162 by each NE to the Mediation service of each NE. When the M2000 is running, ensure that the udpdispatch_agent process works properly. Required services: PartitionService
9.1.66 umgupdsvr_agent Process

This section describes the services and functions provided by the umgupdsvr_agent process. The umgupdsvr_agent process provides the UMGUpgradeService service. UMGUpgradeService provides the UMG upgrade function. Required service: none.
9.1.67 xftpXX01_agent Process

This section describes the services and functions provided by the xftpXX01_agent process.
The xftpXX01_agent process provides the XFTPServiceXX01 service. Through the XFTPServiceXX01 service, the M2000 actively uploads exported files through the northbound interface to the FTP server on the NMS side. The XFTPServiceXX01 service actively checks the alarms, configurations, performance files generated by the PMExport service or the pmexp_agent process. Based on the settings of the FTP server on the NMS side, the XFTPService service uploads the northbound alarm files, configuration files, performance files to the specified FTP server. The files that can be exported by the XFTPServiceXX01 are as follows:
l l l l l l
Northbound alarm file Northbound configuration file Northbound inventory file Northbound performance file CME northbound configuration file NodeB license file
Through the M2000 client, you can set the FTP server on the NMS side. When the M2000 is running, ensure that the xftpXX01_agent process works properly. Required services: none
9.1.68 Processes and Services Related to Each Northbound Interface

This section describes the processes and services related to each northbound interface. Table 9-1 describes the relations between northbound interfaces and their corresponding processes and services. Table 9-1 Relations between northbound interfaces and their corresponding processes and services Process irp_agent Service IRPService Northbound Interface
l
CORBA configuration interface CORBA alarm interface CORBA security interface Configuration database Performance database
l l l l
ifms_agent pmexp_agent
FaultService PMExport
Northbound alarm file interface Northbound performance file interface (measurement unitbased) Northbound performance file interface (NE-based)
Issue 03 (2010-08-31)
medXXXX_agent
MediationServiceXXXX
9-22
Process snmp_agent fmnotify_agent nms_mml_agent cmserver_agent cmexp_agent
Service SnmpAgent FMNotify NMSMMLServer CMServer CMExport
Northbound Interface Northbound SNMP interface Northbound alarm streaming interface Northbound MML interface Northbound inventory file interface Northbound configuration file interface
9.1.69 Checking the Status of the M2000 Processes

This section describes how to check the status of the M2000 processes. When the M2000 processes are not running normally, you need to locate faults and log in to the server to rectify the faults in time.
Prerequisite
l l
Context
Checking the states of the M2000 processes on the M2000 client requires only a few system resources and does not affect system performance.
Procedure
Step 1 Choose Monitor > System Monitor > Monitor Browser. The System Monitor Browser window is displayed. Step 2 Click the Process Monitor tab to check the monitoring data of the processes running on the M2000 server. See Figure 9-1.
Issue 03 (2010-08-31)
9-23
Figure 9-1 Process Monitor tab page
9.2 Managing M2000 Services (HA)

This section describes how to check, start, and stop the services of the M2000 HA system. 9.2.1 Checking the M2000 Services This section describes how to check the M2000 services. When the M2000 services are not running normally, you need to locate faults and log in to the server to rectify the faults in time. 9.2.2 Viewing the States of M2000 Services (HA) This section describes how to view the states of M2000 services on the M2000 server. This operation consumes a few system resources and does not affect system performance. 9.2.3 Starting the M2000 Services (HA) This section describes how to start the M2000 system services. After you run the command, all the M2000 services are started. The system ignores the service that is already started and starts only the inactive services. 9.2.4 Stopping M2000 Services (HA) This section describes how to run the command scswitch to stop all the M2000 services. After all the M2000 services are stopped, NE performance data and alarm data cannot be processed. After the M2000 services are resumed, the M2000 updates data with the NEs and processes the updated data.
9.2.1 Checking the M2000 Services

This section describes how to check the M2000 services. When the M2000 services are not running normally, you need to locate faults and log in to the server to rectify the faults in time.
Prerequisite
l l
Context
Checking the M2000 services on the M2000 client requires only a few system resources and does not affect system performance.
Procedure
Step 1 Choose Monitor > System Monitor > Monitor Browser. The System Monitor Browser window is displayed. Step 2 Click the Service Monitor tab to check the M2000 services. See Figure 9-2. Figure 9-2 Service Monitor tab page
NOTE
In the Status column, the green icon indicates that the corresponding process is normal; the red icon indicates the corresponding process is abnormal.
9.2.2 Viewing the States of M2000 Services (HA)

This section describes how to view the states of M2000 services on the M2000 server. This operation consumes a few system resources and does not affect system performance.
Prerequisite
Log in to the active node as user omcuser through SSH mode.
Procedure
Step 1 Change to the installation directory of the M2000. -bash-3.00$ cd /opt/OMC By default, the installation directory is /opt/OMC. Step 2 Run the following commands to view the state of the M2000 services: -bash-3.00$ . ./svc_profile.sh -bash-3.00$ svc_adm -cmd status
l
In the displayed information, if the state of the service is running, you can infer that the service operate properly. In the displayed information, if the state of the service is not running, you can infer that the service is abnormal.
Service Agent: 3rdTool_agent [1 service(s)] pid: 15490 3rdToolService [running ] ... [All Services: 51 ] [Running: 51 ] [Not Running: 0 ]
NOTE
Host: 10.121.71.242
At the end of the displayed information, if the value of Not Running : is 0, you can infer that all the M2000 services operate properly. If another value is displayed, contact Huawei technical support engineers for assistance. The M2000 system generates processes and services dynamically during operation. Accordingly, the number of processes and services changes dynamically.
----End
9.2.3 Starting the M2000 Services (HA)

This section describes how to start the M2000 system services. After you run the command, all the M2000 services are started. The system ignores the service that is already started and starts only the inactive services.
Prerequisite
l l
Log in to the active node as user root through SSH mode. The Sybase services are running properly. For details about how to start the Sybase services, see 16.2.2 How to Start the Sybase (HA, Sun).
Context
NOTE
The time required for starting M2000 system services is related to the actual environment. Generally, it takes about 20 minutes.
9-26
Issue 03 (2010-08-31)
Procedure
l 1. Run the following command: # scswitch -e -j ossapp_rs
NOTE
l l
In the HA system, starting services requires some time. Wait about 10 minutes until all services are started and then you can perform operations on the HA system. When you start M2000 system services, the status of each service is displayed. If the status of a service is failed, you can infer that the service fails to be started. In this case, you can locate the fault by viewing the iMAP.troubleshooting.trace log on the active node. # more /export/home/omc/var/logs/iMAP.troubleshooting.trace
----End
9.2.4 Stopping M2000 Services (HA)

This section describes how to run the command scswitch to stop all the M2000 services. After all the M2000 services are stopped, NE performance data and alarm data cannot be processed. After the M2000 services are resumed, the M2000 updates data with the NEs and processes the updated data.
Prerequisite
Context
NOTE
The time required for stopping M2000 system services is related to the actual environment. Generally, it takes about 20 minutes.
Procedure
l 1. Run the command: # scswitch -n -j ossapp_rs
NOTE
The HA system takes some time to stop the services. Wait for ten minutes after you run the command. Run the command svc_ps to monitor the service stopping progress.
----End
Issue 03 (2010-08-31)
9-27
10 Managing the M2000 Databases
10
Managing the M2000 Databases
About This Chapter

This chapter describes how to manage the M2000 databases. 10.1 M2000 Database The M2000 databases consist of the Sybase database and the M2000 server database. This chapter describes only the M2000 server database. After the installation of the M2000 server application software, the size of the M2000 server database is fixed. You can use Sybase commands to operate the M2000 server database. 10.2 Viewing the States of M2000 Databases This section describes how to view the states of M2000 databases. You can run Sybase commands on the server to view the states of M2000 databases. Alternatively, you can view the database states using the system monitor browser. 10.3 Clearing M2000 Databases This section describes how to dump the data in the M2000 databases. The data includes the performance data, NE operation logs, NE system logs, NE security logs, alarm/event logs, NM operation logs, NM system logs, and NM security logs. You can configure an integrated task for dumping the data in the M2000 databases. 10.4 Backing Up M2000 Databases This section describes how to back up the M2000 databases. The M2000 databases are categorized into omcdb, fmdb, pmdb, swmdb, itfndb, omclogdb, omcsmdb, omctmdb, pmcomdb, sumdb, farsdb and omceamdb.
Issue 03 (2010-08-31)
10-1
10.1 M2000 Database

The M2000 databases consist of the Sybase database and the M2000 server database. This chapter describes only the M2000 server database. After the installation of the M2000 server application software, the size of the M2000 server database is fixed. You can use Sybase commands to operate the M2000 server database. The function of each M2000 server database is as follows:
l
omcdb: stores the configuration data of the M2000 and the data related to internal feature implementation. The omcdb database must exist in the M2000 system. omclogdb: stores log management data. The omclogdb database must exist in the M2000 system. omcsmdb: stores security management data. The omcsmdb database must exist in the M2000 system. omctmdb: stores topology management data. The omctmdb database must exist in the M2000 system. fmdb: stores the alarm and event logs of the M2000 and NEs. The fmdb database must exist in the M2000 system. pmdb: stores the performance structure tables and performance measurement results of NEs. The pmdb database must exist in the M2000 system. swmdb: stores the files managed by the software management module and the configuration data related to NE versions. The swmdb database must exist in the M2000 system. pmcomdb: stores the static performance measurement data of NEs. The pmcomdb database must exist in the M2000 system. sumdb: stores the summary data of NEs. If the M2000 system is not configured with the PRS, the sumdb database does not exist. itfndb: When installing northbound components, you must create the itfndb database for storing the northbound configuration data, performance tasks, and performance threshold data. The itfndb database must exist in the M2000 system. farsdb: stores the signaling data of all the NEs managed by the M2000. If the M2000 system is not configured with the tracing function, the farsdb database does not exist. omctempdb: stores the buffer data required for internal implementation of the DesktopServiceXXXX service. The omctempdb database must exist in the M2000 system. omceamdb: stores the data of network management objects, such as NEs, subnets, and links. The omceamdb database must exist in the M2000 system.
10.1.1 cmedb Database The cmedb database is used to store the NE configuration data on the CME, including the configuration data in the current and planned data areas. 10.1.2 farsdb Database The farsdb database stores the signaling data of all the NEs managed by the M2000. 10.1.3 fmdb Database This section describes the fmdb database, which stores the alarm and event logs of the M2000 and the managed NEs. 10.1.4 itfndb Database
This section describes the itfndb database, which stores the northbound configuration data, performance tasks, and performance threshold data. 10.1.5 omcdb Database This section describes the omcdb database. The omcdb database stores the M2000 configuration data, security data, and internal data. 10.1.6 omceamdb Database This section describes the omceamdb database. The omceamdb database is used to store the data of network management objects, such as NEs, subnets, and links. 10.1.7 omclogdb Database This section describes the omclogdb database, which stores the M2000 log management data. 10.1.8 omcsmdb Database This section describes the omcsmdb database, which stores the security management data. 10.1.9 omctempdb Database This section describes the omctempdb database. The omctempdb database is used to store the buffer data required for internal implementation of the DesktopServiceXXXX service. 10.1.10 omctmdb Database This section describes the omctmdb database, which stores the topology management data. 10.1.11 pmcomdb Database The pmcomdb database is used for storing the static performance measurement data of NEs. 10.1.12 pmdb Database This section describes the pmdb database, which stores the performance structure tables and performance measurement results of NEs. 10.1.13 sumdb Database The sumdb database stores the summarized performance data of NEs for performance reports. 10.1.14 swmdb Database This section describes the swmdb database, which stores the file information about the software management module and the configuration data of NE versions.
10.1.1 cmedb Database

The cmedb database is used to store the NE configuration data on the CME, including the configuration data in the current and planned data areas. The cmedb database requires at least 10 GB data space. Table 10-1 lists the names and functions of the tables in the cmedb database. Table 10-1 Names and functions of tables in the cmedb database Table Name Utils_TableDef Utils_FieldDef Utils_FieldDefIncludeOpaque Function Records the basic information about the MOC. Records the attribute information about the MOC. Records the attribute information about the opaque.
Issue 03 (2010-08-31)
10-3
Table Name Utils_ErrMsg
Function Records the correspondence between the error code and error description.
10.1.2 farsdb Database

The farsdb database stores the signaling data of all the NEs managed by the M2000. The farsdb database requires at least 10 GB data space and 3 GB log space. If the M2000 system is not configured with the tracing function, the farsdb database is not available. The farsdb database consists of the following types of tables:
l l l
Static configuration data table Task table Task data table
Table 10-2 describes the name and function of each table in the farsdb database. Table 10-2 Tables of the farsdb database and the corresponding functions Table Name tbl_ProcessorInfo tbl_Field tbl_TaskInfo tbl_TaskNE Message type name_task ID Function Static service configuration table Static field configuration table Dynamic task record table Table recording the tasks reported to NEs Task data table created dynamically, which records the signaling data of the message type corresponding to a task
10.1.3 fmdb Database

This section describes the fmdb database, which stores the alarm and event logs of the M2000 and the managed NEs. The space of the fmdb database must be greater than 3,700 MB. Table 10-3 lists the names and functions of tables in the fmdb database. Table 10-3 Tables of the fmdb database and the corresponding functions Table Name tbl_alm_log
10-4
Function Records alarm logs.

Table Name tbl_event_log Other tables
Function Records event logs. Record the internal processing data of alarms.
NOTE
The system automatically divides the tbl_alm_log and tbl_event_log tables according to the size of alarms and events. For example, the fmdb database may contain multiple alarm log tables such as tbl_alm_log_1 and tbl_alm_log_2.
10.1.4 itfndb Database

This section describes the itfndb database, which stores the northbound configuration data, performance tasks, and performance threshold data. The itfndb database is optional. It requires a disk space of at least 200 MB. Table 10-4 lists the name and function of each table. Table 10-4 Tables of the itfndb database and the corresponding functions Table Name tbl_JGeneralInfo tbl_JMoInstance tbl_JStatusRecord tbl_JMeasurementCategory tbl_JSchedule tbl_MGeneralInfo tbl_MMoInstance tbl_MMeasurementCategory tbl_MThresholdPackElemen tbl_MAlarmRecord tbl_MStatusRecord Other tables Function Records the general information about tasks. Records the instances of tasks. Records the Status of tasks. Records the measurement categories of tasks. Records the task scheduling. Records the general information about thresholds. Records the instances of thresholds. Records the measurement categories of thresholds. Records the details of thresholds. Records the alarm records of thresholds. Records the status of thresholds. Records the information about northbound implementation.
10.1.5 omcdb Database

This section describes the omcdb database. The omcdb database stores the M2000 configuration data, security data, and internal data. The omcdb database requires at least 1,000 MB data space.
Table 10-5 lists the names and functions of the tables in the omcdb database. Table 10-5 Names and functions of tables in the omcdb database Table Name Tables with moi_ as the prefix Tables with mos_ver_ as the prefix Tables with nbmmlNe_ as the prefix Tables with sm_ as the prefix Tables with softx3000_ as the prefix Views with gv_view_cmcyw_ as the prefix Views with view_cmcyw_ as the prefix tbl_AllNeInfo Processes with proc_sm_ as the prefix Processes with sm_ as the prefix tbl_Resource Tables with ums_ as the prefix Tables with ne_ as the prefix Tables with omc_ as the prefix Tables with rel_ as the prefix tbl_ADAllNeList tbl_ADNeStatus tbl_AllNeInfo tbl_IPExg tbl_OmcSslOption tbl_nelicBaseInfo Function Records the information about MO examples. Records the information about versions. Records the information about the format of messages transferred between the and the NEs. Records the information about service data. Records dual-homing relationship. Records service Database Central (DC) data. Records basic service data. Records information about NEs. Records the processes of service data. Records the processes of service AMG data. Records NE resource data. Record the information about error codes. Records the information about NE models. Records the data about network management. Records the associations between MOs. Records the information about the NodeBs to be commissioned. Records the information about the statuses of the NodeBs to be commissioned. Records the network management data. It is created to ensure that the M2000 is compatible with earlier versions. Records the IP configuration information about the NAT translation table. Records the SSL connection policy of the OMC for NEs. Records the basic information about NEs.
10-6
Issue 03 (2010-08-31)
Table Name tbl_nelicTask tbl_nelicTaskEnv tbl_test_task_property tbl_test_local_path tbl_test_other_path tbl_test_log_result tbl_test_ping_report tbl_test_audit_result tbl_test_nblink_result tbl_test_ping_address tbl_SubareaInfo tbl_SubareaRes session_SessionEntity session_SessionMoc session_SessionOpInfo Other tables
Function Records the information about operation tasks. Records the information flow interacted between the M2000 server and client. Records the properties of the IPQoS test task. Records the intra-office test path. Records the inter-office test path. Records the test task logs. Records the signaling parameters on the bearer network. Records the audit results of calling and called parties on the bearer network. Records the audit result of the call completion rate on the bearer network. Records the information about address pairs sent by the host. Refers to the partition information table, which records the information about each node. Refers to the partition resource table, which records the resources of each node. Records the information about the operated NEs during a session. Records the information about the operated MOCs during a session. Records the information about the user operations during a session. Records other configuration data of the M2000.
10.1.6 omceamdb Database

This section describes the omceamdb database. The omceamdb database is used to store the data of network management objects, such as NEs, subnets, and links. The omceamdb database requires more than 500 MB disk space. Table 10-6 lists the name and function of each table in the omceamdb database.
Issue 03 (2010-08-31)
10-7
Table 10-6 Name and function of each table in the omceamdb database Table Name tbl_sn tbl_ne tbl_nefeature tbl_link tbl_idresource tbl_sntype tbl_netype tbl_linktype tbl_sync tbl_nerelation tbl_maintenanceinfo tbl_locationinfo tbl_negroup tbl_negroupclass tbl_negroup2ne tbl_negrouptype tbl_devsnmppara tbl_dftsnmppara tbl_autodiscfilter tbl_autodischistory tbl_eamschedule tbl_autodiscresult Function Subnet information table NE information table NE feature table Link information table NMS object identification management table Subnet type table NE type table Link type table Data synchronization table NE relation table Maintenance personnel information table Device maintenance information table NE group information table NE group mode table NE group and NE relation table NE group type table SNMP device parameter table Default SNMP parameter table Auto-search IP filter table Auto-search history record table Scheduled-search parameter table Auto-search result table
10.1.7 omclogdb Database

This section describes the omclogdb database, which stores the M2000 log management data. The omclogdb database requires more than 500 MB disk space. Table 10-7 lists the names and functions of the tables in the omclogdb database.
10-8
Issue 03 (2010-08-31)
Table 10-7 Names and functions of the tables in the omclogdb database Table Name tbl_Audit tbl_SysLog tbl_SysLogResultDef tbl_SysLogStaticInfo Other tables Function Records the logs of user operations. Records the logs of system operations. Records the result information about system logs. Records the static information about system logs. Records the information about other logs.
10.1.8 omcsmdb Database

This section describes the omcsmdb database, which stores the security management data. Table 10-8 lists the names and functions of the tables in the omcsmdb database. Table 10-8 Tables of the omcsmdb database and the corresponding functions Table Name tbl_AccessTable tbl_AccessViewNodeRelTable tbl_AccessViewNodeTable tbl_IDTable tbl_SMAccessPolicyItem tbl_SMGroup tbl_SMGroupUserMap tbl_SMLoginRec tbl_SMNEUser tbl_SMPrivateGroupUserMap tbl_SMSecurityPolicy tbl_SMTerm tbl_SMUser tbl_SMUserHistoryRec Function Records the binding relations between user groups and privileges. Records the relations between the privilege display nodes. Records the privilege display nodes. Records the reclaimed IDs. Records the privilege statistics for binding user groups. Records the basic information about user groups. Records the binding relations between user groups and users. Stores the history records on user login. Records the basic information about NE users. Records the binding relations between private groups and users. Records the security policy. Records the basic information about terminals. Records the basic information about users. Records history user passwords.
Issue 03 (2010-08-31)
10-9
Table Name tbl_SMUserNEUserMap tbl_SMUserTerminalMap tbl_SecurityObjectTable tbl_SessionIDTable tbl_StaticTypeRelationTable tbl_StaticTypeTable tbl_StaticTypeViewTable
Function Records the binding relations between users and NE users. Records the binding relations between users and terminals. Records security objects. Records session IDs. Records the relations between privileges. Records the static security information about object types, privileges, and operations. Records the static security information.
10.1.9 omctempdb Database

This section describes the omctempdb database. The omctempdb database is used to store the buffer data required for internal implementation of the DesktopServiceXXXX service. The omctempdb database requires more than 500 MB disk space. Table 10-9 lists the name and function of each table in the omctempdb database. Table 10-9 Name and function of each table in the omctempdb database Table Name tbl_instance name_subsystem name_function name Function Stores the buffer data required for internal implementation of the DesktopServiceXXXX service.
10.1.10 omctmdb Database

This section describes the omctmdb database, which stores the topology management data. The omctmdb database requires a disk space of more than 550 MB. Table 10-10 lists the names and functions of the tables in the omctmdb database. Table 10-10 Names and functions of the tables in the omctmdb database Table Name MOTSConfig MOTSDomain
10-10
Function Records the topology configuration values, including the initial value and the maximum value assigned by ObjID. Records the information on topology domains.
Issue 03 (2010-08-31)
Table Name MOTSLink MOTSNode MOTSSubnet MOTSSubtree MOTSVSubnet MOTSView MOTSViewObj TSTempLoc TSTempPos
Function Records the information on topology links. Records the information on topology NEs. Records the information on topology subnets. Records the information on the topology tree. Records the information on topology logical subnets. Records the information on topology views. Records the information on topology view objects. Records the temporary table that stores the longitude and latitude coordinates of the e-map. Records the temporary table that stores the x-axis and y-axis coordinates of common physical topology.
10.1.11 pmcomdb Database

The pmcomdb database is used for storing the static performance measurement data of NEs. The space of the pmcomdb database must be greater than 400 MB. If the remaining space of the pmcomdb database is insufficient, the system generates an alarm. The pmcomdb database consists of the following types of tables:
l l l
Counter tables Template Tables Function Subsets and Period Tables
Counter tables
Compared with the data in other types of tables, the data in these tables is stable. Table 10-11 lists the name and function of each table. Table 10-11 Counter information tables in the pmcomdb database and the corresponding functions Table Name systbl_NeType systbl_FunctionSet systbl_FunctionSubSet systbl_Counters
Issue 03 (2010-08-31)
Function Records all possible NE types in M2000. Records the function sets of all NEs. Records the measurement units of all function sets. Records all measurement counters.
10-11
Table Name systbl_Counter_Unit systbl_AllCounterCategory systbl_ComputeCounters
Function Records the units of all counters. Records the service features of each version. Records only the counters involved in calculation.
Template Tables
Template tables contain several tables that record measurement information. Table 10-12 lists the name and function of each table. Table 10-12 Template information tables in the pmcomdb database and the corresponding functions Table Name tbl_ObjectInstance tbl_MeasurementPeriod tbl_MeasurementCounter tbl_MeasurementSuspendInfo tbl_CounterCategory tbl_CounterLevel tbl_FeatureStatus Function Records measurement objects. Records measurement periods. Records measurement counters. Records the information on suspended tasks. Records the status of each service feature. Records the status of each service counter. Records the status of all the service features on the M2000 operating environment.
Function Subsets and Period Tables

The measurement results are saved according to the function subset and period. Table 10-13 lists the name and function of each subset and table.
10-12
Issue 03 (2010-08-31)
Table 10-13 Function subsets and period tables in the pmcomdb database and their functions Table Name tbl_MeasObject_XXX_Y Function In the table name, XXX refers to the function subset ID and Y refers to the period index that ranges from 0 to 4. By comparing the tbl_MeasObject_XXX_Y with the result table named tbl_Result_XXX_Y, you can check the loss status and integrity of the results. Each time when the measured object changes, a message is recorded in the list.
10.1.12 pmdb Database

This section describes the pmdb database, which stores the performance structure tables and performance measurement results of NEs. The pmdb database stores the NE performance measurement data. A disk space of more than 13,000 MB is required for the storage. If the pmdb database is fully occupied, the M2000 raises an alarm. After the storage period of the performance measurement data expires, the most recent data overwrites the earlier data on a daily basis. If the data is saved for less than 30 days old but the pmdb database is fully occupied, you must change the number of days till when the data can be stored. Otherwise, the pmdb database is suspended and it cannot process any performance data from the NEs. Change the number of saving days when the remaining space of the pmdb database is insufficient. To calculate the number of days till when the data can be stored, perform the following steps: 1. 2. 3. Observe the usage of the pmdb database when the M2000 runs for half a month. Calculate the space of the pmdb database used a day. Calculate the number of days that the pmdb database lasts.
The pmdb database consists of the following types of tables:

l l
Template Tables Function Subsets and Period Tables
Template Tables
Template tables record measurement information. Table 10-14 lists the name and function of the table.
Issue 03 (2010-08-31)
10-13
Table 10-14 Template tables in the pmdb database and their functions Table Name tbl_SyncInfo Function Records the supplementary collection queues of performance results.
Function Subsets and Period Tables

The pmdb database stores the tables of measurement results categorized by function subsets and periods. Table 10-15 lists the name and function of the table. Table 10-15 Function subset tables and period tables in the pmdb database and the corresponding functions Table Name tbl_Result_XXX_Y Function Records periodic results. In the table name, XXX is the ID of the function subset and Y is the period index between 0 and 4.
10.1.13 sumdb Database

The sumdb database stores the summarized performance data of NEs for performance reports. The size of the sumdb database equals to one thirds of the size of the pmdb database. That is, at least 4,500 MB database space is required. If the M2000 system is not configured with the PRS, the sumdb database is not available. The sumdb database consists of the following types of tables:
l l l l
Object type information table System setting information table Report information table Performance result table
Object Type Information Table

The object type information table consists of 12 tables, which save a group of relatively stable information. Table 10-16 lists the name and function of each table. Table 10-16 Name and function of each object type information table in the sumdb database Table Name t_NeType t_PRSObjectType
10-14
Function Records the NE type and manages the relevant information. Records the information about object types of each class.
Issue 03 (2010-08-31)
Table Name t_GroupObjType t_AttrObjType t_ConfigObjType t_ConfigObjTypeAttr t_CombObjType t_PmObjType t_CombTable t_FSS t_Item t_ObjTypeAggrRelation
Function Records the information about object types of object groups. Records the information about object types of attribute classes. Records the information about object types of configuration classes. Records the attribute information about the configuration object type. Records the information about object types of combination classes. Records the relation between the PRS object type and the performance object type. Records the rule information about the combination table. Records the information about the extracted function subsets. Records counter information. Records the summarization relation between objects.
System Setting Information Table

The system setting information consists of 15 tables that record information related to system setting. Table 10-17 lists the name and function of each table. Table 10-17 Name and function of each system setting information table in the sumdb database Table Name t_Week t_SpecialDate t_BusyRule t_BusyTime t_BusyTimeArith t_DefaultPeriod t_RawPeriod t_DefaultStorage t_CustomStorag Function Records the start date of a week. Records the definition information about special dates. Records the information about busy-hour planning. Records the information about busy hours. Records the information about the statistics on monthly busy hours. Records the information about default periods. Records the information about the extraction period of original results. Records the default storage duration of results. Records the storage duration of results.
Issue 03 (2010-08-31)
10-15
Table Name t_LoadFlag t_MaxItemId t_RawHistoryInf t_RawResultNo t_SumHistoryInfo t_BusyHistoryInfo
Function Records the information about the summarization and extraction. Records the IDs of maximum available counters of NEs. Records the history of extracting original result tables. Records the result numbers of original result tables. Records the history of extracting summarization result tables. Records the information about busy-hour summarization result tables.
Report Information Table

The report information table consists of eight tables that record the information about the queried tables. Table 10-18 lists the name and function of each table. Table 10-18 Name and function of each report information table in the sumdb database Table Name t_Report t_Sheet t_SheetItem t_SheetFilter t_ItemFormat t_RelateReport t_TemplateInfo t_TemplateObjInfo Function Records the information about reports. Records the information about the sheets. Records the counters of sheets. Records filtering information. Records the counter format information. Records the relation between reports. Records the basic information about the templates. Records the basic information about the templates and the objects.
Performance Result Table

The performance result table consists of multiple tables, which records the performance measurement results based on the function subset and the measurement period. Table 10-19 lists the name and function of each table. In Table 10-19, fssName, ObjLevel, and XXX in the tables whose names begin with d_ can be configured in the configuration file.
l l
fssName refers to the name of a function subset. ObjLevel refers to the dimension of an object.
10-16

l
In the tables whose names begin with d_, XXX refers to the ID of an object type.
Table 10-19 Name and function of each performance result table in the sumdb database Table Name f_fssName_Raw Function Indicates original result serial tables which record the original results. If the function subset is not extracted internally, the administration tool (AT) automatically names the function subset in the following format: F + ID of the function subset. f_fssName_ObjLevel_H Indicates hourly serial tables which records the result information at hour dimension. The hourly summarization is based on the original results. Indicates daily serial tables which record the result information at day dimension. The hourly summarization is based on hourly summarization. Indicates daily serial tables which record the result information at week dimension. The weekly summarization is based on daily summarization. Indicates monthly serial tables which record the result information at month dimension. The monthly summarization is based on weekly summarization. Indicates the weekly busy-hour serial tables which record the weekly busy-hour results. Indicates the monthly busy-hour serial tables which record the monthly busy-hour results. Records the information about the objects to be configured. Records the information about the type of object groups. Records the information about object instances of object groups.
f_fssName_ObjLevel_D
f_fssName_ObjLevel_W
f_fssName_ObjLevel_M
f_fssName_ObjLevel_WH f_fssName_ObjLevel_MH d_XXX d_XXXGrp d_XXXGrpObject
10.1.14 swmdb Database

This section describes the swmdb database, which stores the file information about the software management module and the configuration data of NE versions. The swmdb database stores the files managed by the software management module and the NE version configuration data. A disk of more than 3,000 MB is required for storage. Table 10-20 lists the name and function of each table.
Issue 03 (2010-08-31)
10-17
Table 10-20 Tables of the swmdb database and the corresponding functions Table Name tbl_FTPFileSet tbl_VersionRelation tbl_NELogTable Function Records the files managed by the software management module. Records the information about version relations. Records the NE operation logs.
10.2 Viewing the States of M2000 Databases

This section describes how to view the states of M2000 databases. You can run Sybase commands on the server to view the states of M2000 databases. Alternatively, you can view the database states using the system monitor browser. 10.2.1 Checking the Database Usage Information About the M2000 Server Through the M2000 Client This section describes how to check the database status through the M2000 client to know the usage of the databases. 10.2.2 Viewing the Database Usage of the M2000 Server Using Sybase Commands This section describes how to view the database status of the M2000 server by using Sybase commands. This operation requires very few system resources and does not affect system operation.
10.2.1 Checking the Database Usage Information About the M2000 Server Through the M2000 Client
This section describes how to check the database status through the M2000 client to know the usage of the databases.
Prerequisite
l l
Context
This operation requires only a few system resources and does not affect system operation.
Procedure
Step 1 Choose Monitor > System Monitor > Monitor Browser. The System Monitor Browser window is displayed. Step 2 Click the Database Monitor tab to check the database status of the M2000 server. See Figure 10-1.
10-18
Issue 03 (2010-08-31)
Figure 10-1 Database Monitor tab page
NOTE
In the Status column, the green icon indicates that the usage of the corresponding database is normal; the red icon indicates that the usage of the corresponding database is abnormal. If the usage of a database exceeds the preset threshold, the icon in this column changes from green to red.
10.2.2 Viewing the Database Usage of the M2000 Server Using Sybase Commands
This section describes how to view the database status of the M2000 server by using Sybase commands. This operation requires very few system resources and does not affect system operation.
Prerequisite
l
Log in to the M2000 server as user dbuser through SSH mode. In the HA system, log in to the active node. The Sybase service is running.
Context
In addition to the method described in 10.2.1 Checking the Database Usage Information About the M2000 Server Through the M2000 Client, you can use the Sybase commands to view the disk usage of the M2000 server.
Procedure
Step 1 Check all the databases of the M2000 server.
-bash-3.00$ isql -Sdatabase server name -Usa -Ppassword of user sa 1> sp_helpdb 2> go
NOTE
After the Sybase server is started, run the following command to view the name of the database server: -bash-3.00$ ps -ef | grep RUN_ | grep -v grep In the command result, the value after the RUN_ is the name of the database server. As shown in the following command result, the name of the database server in this example is SYB:
dbuser 17046 dbuser 17050 1 1 0 0 Dec 11 ? Dec 11 ? 0:00 /bin/sh ./RUN_SYB 0:00 /bin/sh ./RUN_SYB_back
Step 2 View the database usage and the event log space usage. 1> sp_helpdb M2000 database name 2> go To view the usage of the pmdb database, run the following command: 1> sp_helpdb pmdb 2> go
name db_size status owner dbid created
------------ ------------- ------ ------ ----------------------------------------------------------------------------------------------------------------------------------------pmdb 13000.0 MB sa 9 Mar 13, 2007 select into/bulkcopy/pllsort, trunc log on chkpt (1 row affected) device_fragments size usage created free kbytes ------------------------------ ------------- ------------------------------------------- ---------------data001_dev 10000.0 MB data only Mar 13 2007 6:37PM 10193312 log001_dev 3000.0 MB log only Mar 13 2007 6:37PM not applicable -------------------------------------------------------------------------------log only free kbytes = 3059992 (return status = 0)
As shown in the previous command result, the occupied space of the pmdb database is 13,000 MB, where 10,000 MB is used for storing performance data and 3,000 MB is used for storing the performance log data. In the 10,000 MB data space, the free space is 10,193,312 KB. Therefore, the usage is 0.46%. In the 3,000 MB log space, the free space is 3,059,992 KB. Based on the database usage and the preset threshold, you can determine whether the database status is normal. Run the following command to exit:
1>exit ----End
10.3 Clearing M2000 Databases

This section describes how to dump the data in the M2000 databases. The data includes the performance data, NE operation logs, NE system logs, NE security logs, alarm/event logs, NM operation logs, NM system logs, and NM security logs. You can configure an integrated task for dumping the data in the M2000 databases.
Prerequisite
l l
You have logged in to the M2000. You are authorized to clear the M2000 databases.
Context
l
Dump conditions can be set according to the following aspects: execution type, execution time, and file saving format. After the data is dumped, the following data is saved in the default directory of the M2000 server and removed from the databases:

The performance data in the pmdb database The NE operation logs, NE system logs, and the NE security logs in the swmdb database The alarm and event logs in the fmdb database The operation logs, system logs, and security logs in the omclogdb database
Procedure
Step 1 Dump the performance data in the pmdb database. 1. On the GUI of the M2000 client, choose Maintenance > Task Management. The Task Management window is displayed. 2. 3. 4. In the left part of the Task Management window, select Performance Data under the Database Capacity Management node from the Task Type navigation tree. Select a task in the right part of the Task Management window, and then click Attribute. In the Attribute dialog box, set the dump parameters. Then, click OK.
Step 2 Dump the NE operation logs in the swmdb database. 1. On the GUI of the M2000 client, choose Maintenance > Task Management. The Task Management window is displayed. 2. 3. 4.
Issue 03 (2010-08-31)
In the left part of the Task Management window, select NE Operation Log under the node Database Capacity Management from the Task Type navigation tree. Select a task in the right part of the Task Management window, and then click Attribute. In the Attribute dialog box, set the dump parameters. Then, click OK.
Step 3 Dump the NE security logs in the swmdb database. 1. On the GUI of the M2000 client, choose Maintenance > Task Management. The Task Management window is displayed. 2. 3. 4. In the left part of the Task Management window, select NE Security Log under the node Database Capacity Management from the Task Type navigation tree. Select a task in the right part of the Task Management window, and then click Attribute. In the Attribute dialog box, set the dump parameters. Then, click OK.
Step 4 Dump the NE system logs in the swmdb database. 1. On the GUI of the M2000 client, choose Maintenance > Task Management. The Task Management window is displayed. 2. 3. 4. In the left part of the Task Management window, select NE System Log under the node Database Capacity Management from the Task Type navigation tree. Select a task in the right part of the Task Management window, and then click Attribute. In the Attribute dialog box, set the dump parameters. Then, click OK.
Step 5 Dump the alarm and event logs in the fmdb database. 1. On the GUI of the M2000 client, choose Maintenance > Task Management. The Task Management window is displayed. 2. 3. 4. In the left part of the Task Management window, select Alarm/Event Log Dump under the node Database Capacity Management from the navigation tree Task Type. Select a task in the right part of the Task Management window, and then click Attribute. In the Attribute dialog box, set the dump parameters. Then, click OK.
Step 6 Dump the NM operation logs in the omclogdb database. 1. On the GUI of the M2000 client, choose Maintenance > Task Management. The Task Management window is displayed. 2. 3. 4. In the left part of the Task Management window, select NM Operation Log Dump under the Database Capacity Management node from the Task Type navigation tree. Select a task in the right part of the Task Management window, and then click Attribute. In the Attribute dialog box, set the dump parameters. Then, click OK.
Step 7 Dump the NM system logs in the omclogdb database. 1. On the GUI of the M2000 client, choose Maintenance > Task Management. The Task Management window is displayed. 2. 3. 4.
10-22
In the left part of the Task Management window, select NM System Log Dump under the Database Capacity Management node from the Task Type navigation tree. Select a task in the right part of the Task Management window, and then click Attribute. In the Attribute dialog box, set the dump parameters. Then, click OK.
Step 8 Dump the NM security logs in the omclogdb database. 1. 2. 3. 4. On the GUI of the M2000 client, choose Maintenance > Task Management. The Task Management window is displayed. In the left part of the Task Management window, select NM Security Log Dump under the Database Capacity Management node from the Task Type navigation tree. Select a task in the right part of the Task Management window, and then click Attribute. In the Attribute dialog box, set the dump parameters. Then, click OK.
----End
10.4 Backing Up M2000 Databases

This section describes how to back up the M2000 databases. The M2000 databases are categorized into omcdb, fmdb, pmdb, swmdb, itfndb, omclogdb, omcsmdb, omctmdb, pmcomdb, sumdb, farsdb and omceamdb.
Prerequisite
l l
You have logged in to the M2000 client. You are authorized to back up the M2000 system.
Context
NOTE
The time required for backing up data is related to the actual environment. Generally, it takes about five hours. Do not suspend a periodic backup task. The reasons are as follows:
l l
The latest data fails to be restored after data lost caused by an accident, for example, the power-off of the server. The database logs dumped by the Sybase database are not cleared in time, which causes /export/ home to be used up.
Procedure
Step 1 On the main window, choose Maintenance > Task Management. The Task Management dialog box is displayed. Step 2 Choose Task Type > Backup > Server Backup from the navigation tree, and then double-click the Server Backup node. The Attribute dialog box is displayed, as shown in Figure 10-2.
Issue 03 (2010-08-31)
10-23
Figure 10-2 Periodic backup
Step 3 Click the Common Parameters tab, and then set Task Name and Start Time. If the current time zone supports DST, the DST check box is available. The Start Time can be calculated by setting the DST. Step 4 Click the Extended Parameters tab, and then set Server Full Backup Date, as shown in Figure 10-3.
10-24
Issue 03 (2010-08-31)
Step 5 Click OK. The system periodically backs up data. ----End
Issue 03 (2010-08-31)
10-25
11 Managing the M2000 Files and Disks (HA)
11
Managing the M2000 Files and Disks (HA)
About This Chapter

This chapter describes how to manage the file systems and disks on the M2000 server and client. 11.1 Managing Files and Disks on M2000 Clients This section describes how to manage the file systems and disks on the M2000 clients. 11.2 Managing Files and Disks on the M2000 Server (HA) This section describes how to manage the file systems and disks on the M2000 server.
Issue 03 (2010-08-31)
11-1
11.1 Managing Files and Disks on M2000 Clients

This section describes how to manage the file systems and disks on the M2000 clients. 11.1.1 Introduction to the M2000 Client File System This introduces the M2000 client file system. 11.1.2 Clearing the Disk Space of an M2000 Client This section describes how to clear the disk space of an M2000 client. Before performing this operation, ensure that the files to be deleted are not required for future operations. Deleting a useful file by mistake may lead to a system operation error.
11.1.1 Introduction to the M2000 Client File System

This introduces the M2000 client file system. The client software runs on the Windows operating system and is based on the JAVA virtual machine. The installation package of the M2000 client software includes the JAVA virtual machine supported by Windows. Required client disk space (only for reference): F = I + T + (S x N), where I refers to the size of the initial version, that is, about 300 MB; T refers to the temporary space for saving patches, which is less than 20 MB; S refers to the size of mediation files, which ranges from 3 MB to 10 MB; N refers to the number of NE versions, which depends on the actual situation. Table 11-1 describes the parameters specified in the equations. Table 11-1 M2000 client software directory Directory client installation path Description Refers to the installation path of the M2000 client software. The default path is C: \iManagerM2000ClientClient. Refers to the path for saving client programs. Refers to the path for saving executable files. Refers to the path for saving NE configuration files. Refers to the path for saving the information that is used for locating problems.
NOTE This path appears only after you run the M2000 diagnosis tool.
M2000 client installation path\client M2000 client installation path\client\bin M2000 client installation path\client \Data M2000 client installation path\client \diagnosis
M2000 client installation path\client \ext_runcfg M2000 client installation path\client\dtd M2000 client installation path\client \IDAPI32
11-2
Refers to the path for saving the configuration files of integrated components. Refers to the path for saving .dtd files. Refers to the path for saving the localWS dynamic link libraries.
Issue 03 (2010-08-31)
Directory M2000 client installation path\client\lib M2000 client installation path\client \localWs M2000 client installation path\client \style M2000 client installation path\client \Templates M2000 client installation path\client\tmp M2000 client installation path\client \tracefile M2000 client installation path\client \update M2000 client installation path\client\cbb M2000 client installation path\client \configuration M2000 client installation path\client \features M2000 client installation path\client \plugins M2000 client installation path\uninstall M2000 client installation path\script M2000 client installation path\client\bin \run
Description Refers to the path for saving the library files. Refers to the path for saving LocalShell that is used to start the 2G LMT. Refers to the path for saving the configuration files of the client. Refers to the path for saving the mapping between administrative regions and their IDs. Refers to the path for saving temporary files during the upgrade. Refers to the path for saving trace files. Refers to the path for saving upgrade files. Refers to the path for saving the CBB files of the M2000 client. Refers to the buffer path of the M2000 client. The path automatically generates when the client is started. Refers to the path for saving the feature configuration file of each subsystem of the M2000 client. Refers to the path for saving the configuration file of each subsystem of the M2000 client as plug-ins. Refers to the path for saving the uninstallation program. Refers to the root path of the iSStar script. Refers to the path for saving the startup parameter configuration files of the client and components.
Issue 03 (2010-08-31)
11-3
Directory M2000 client installation path\cau
Description Refers to the path for saving the Client Auto Upgrade (CAU) client software and the version, document abstract, and group information about the M2000 client.
NOTE
l The CAU client software provides the upgrade
detection mechanism that is based on the document abstract for comparing the document abstract of the server with that of the client. If the document abstracts are not consistent, you need to upgrade the client.
l Based on the group information, the server groups
and packs all the client documents deployed on the server so that the client can download, install, and upgrade these documents. Based on the group information, the client also groups and packs all the client files. Therefore, these files can be compared with those grouped and packed by the server after being downloaded.
M2000 client installation path\jre M2000 client installation path\lib
Refers to the path for saving the Java virtual machine delivered with the M2000 client. Refers to the path for saving the dynamic libraries shared among the M2000 client, remote alarm notification client, script framework client, and data management client. Refers to the path of the remote alarm notification tool. Refers to the path of the trace review tool.
M2000 client installation path\notify M2000 client installation path \TrafficReview
11.1.2 Clearing the Disk Space of an M2000 Client

This section describes how to clear the disk space of an M2000 client. Before performing this operation, ensure that the files to be deleted are not required for future operations. Deleting a useful file by mistake may lead to a system operation error.
Context
CAUTION
You can delete the files when the client is running. Do not delete the files generated on that day. During the routine O&M, back up and clear the following files:
l
Trace logs
11-4

l
Temporary files after the running of the M2000 log collector
Procedure
l Delete the trace logs. Delete the history trace logs saved in the directory M2000 client installation path\client \tracefile. It is recommended that you preserve the trace logs generated in the latest two weeks. l Delete the temporary files generated after the running of the M2000 log collector. Delete the temporary files that are generated after the running of the M2000 log collector and are saved in the directory M2000 client installation path\client\diagnosis. ----End
11.2 Managing Files and Disks on the M2000 Server (HA)

This section describes how to manage the file systems and disks on the M2000 server. 11.2.1 Introduction to the M2000 Server File System (HA) This introduces the structure of the M2000 server files and the planning of disk partition for various server types. The server communicates with the NEs, stores the operation and maintenance data of the NEs, and provides an interface to the NMS. 11.2.2 Viewing the Disk Usage of the M2000 Server Using Solaris Commands This section describes how to use Solaris commands for viewing the disk usage of the M2000 server. This task uses very few system resources and does not affect the system operation. 11.2.3 Clearing the Disk Space of the M2000 Server This section describes how to clear the disk space of the M2000 server. Before clearing disk space, ensure that the files to be deleted are useless. Deleting a useful file by mistake may lead to a system failure.
11.2.1 Introduction to the M2000 Server File System (HA)

This introduces the structure of the M2000 server files and the planning of disk partition for various server types. The server communicates with the NEs, stores the operation and maintenance data of the NEs, and provides an interface to the NMS. The M2000 server runs on the Solaris platform. The M2000 system operation requires the following software:
l l l
Sybase database CORBA supporting software FTP supporting software
The installation package of the M2000 server software includes the software providing the File Transfer Protocol (FTP) and Common Object Request Broker Architecture (CORBA) functions. Table 11-2 lists the directories related to the M2000 server software.
Issue 03 (2010-08-31)
11-5
Table 11-2 Directories for storing the M2000 server software Directory M2000 server installation directory Description M2000 server installation directory refers to the installation directory of the M2000 server software. By default, the installation directory is /opt/OMC. Refers to the directory for storing the third-party software. Refers to the directory for storing the files related to the apache httpd. Refers to the directory for storing executable files. Refers to the directory for storing the CAU components. Refers to the directory of the M2000 client that is deployed on the M2000 server. Refers to the directory for storing the common files of the core network. Refers to the PRS control directory. Refers to the directory for storing the configuration file of universal devices, the configuration file of engineering documents and the C++ control program of the HedEx. Refers to the directory for storing the compressed component files. Refers to the directory for storing the files related to the DesktopService service. Refers to the directory for storing the system configuration files and structured query language (SQL) scripts. Refers to the directory for storing the platform script files. Refers to the directory for storing the HedEx program. Refers to the directory for storing the initialization script file that should be executed during the M2000 installation. Refers to the directory for storing the script files used for installing the M2000. Refers to the directory for storing library files.
M2000 server installation directory/ 3rdTools M2000 server installation directory/ apache2 M2000 server installation directory/ bin M2000 server installation directory/ cau M2000 client installation path/client M2000 server installation directory/ component M2000 server installation directory/ components M2000 server installation directory/ conf
M2000 server installation directory/ data M2000 server installation directory/ds M2000 server installation directory/ etc M2000 server installation directory/ hascript M2000 server installation directory/ helper M2000 server installation directory/ init M2000 server installation directory/ install M2000 server installation directory/lib
11-6
Issue 03 (2010-08-31)
Directory M2000 server installation directory/ lbin M2000 server installation directory/ jre M2000 server installation directory/ med M2000 server installation directory/ medshare M2000 server installation directory/ nhc M2000 server installation directory/ nic M2000 server installation directory/ plugins M2000 server installation directory/ res M2000 server installation directory/ resourcemonitor M2000 server installation directory/ sacscript M2000 server installation directory/ server M2000 server installation directory/ sso M2000 server installation directory/ swapfiles M2000 server installation directory/ tomcat M2000 server installation directory/ tools M2000 server installation directory/ var M2000 server installation directory/ uninstall M2000 server installation directory/ upgrade
Issue 03 (2010-08-31)
Description Refers to the directory for storing the system administration commands. Refers to the JRE directory shared by the client components. Refers to the directory for storing the mediationrelated files generated during the operation. Refers to the directory for storing the mediation files. Refers to the directory for storing the key static files required for generating the NHC reports. Refers to the directory for storing the key static files required for generating the network information collecting reports. Refers to the directory for storing the dynamic library files and configuration files related to plugins. Refers to the directory for storing resource files. Refers to the directory for storing the resource monitoring files. Refers to the directory for storing the script files provided by the NIC module. Refers to the directory for storing the dynamic library files related to M2000 alarms. Refers to the directory for storing the SS0 program files. Refers to the temporary switch directory. Refers to the directory for storing the configuration data of the webpage server. Refers to the directory in which the common script tools of the M2000. Refers to the directory for storing the log files, performance files, and files recording exported alarms. Refers to the directory for storing the script file used for uninstalling the M2000. Refers to the directory for storing the upgrade scripts.
11-7
Directory M2000 server installation directory/ webapps /export/home/omc/var /export/home/omc/var/syslog /export/home/sysm/ftproot/pm
Description Refers to the directory for storing the webpage service files. Refers to the directory for storing the M2000 operation data. Refers to the directory for storing system logs. Refers to the directory for storing the traffic measurement data of each NE, which is reported as files,. Refers to the directory for storing the northbound CORBA interface performance files. Refers to the directory for storing the configuration data files that are periodically exported. Refers to the directory for storing the exported performance result files. Refers to the directory for storing the NE version package. Refers to the directory for storing the NE data backup.
NOTE
l The NE FDN is a code representing an NE sample in
M2000 server installation directory/ var/itf_n/FileTransferIRP/PM /export/home/omc/var/fileint/cm /export/home/omc/var/fileint/pm /export/home/sysm/ftproot/NE name/Software /export/home/sysm/ftproot/NE name/Data/NE fdn
the program.
l The data generated for manual backup is located in the
BAKDATA****** directory. The data generated for automatic backup is located in the AUTOBAKDATA****** directory.
/export/home/omc/var/logs /opt/sybase/ASE-15_0/install /var/adm /export/home/backup/omc /export/home/omc/var/etc/conf/ license /export/home/omc/sso
Refers to the directory for storing the M2000 log files. Refers to the directory for storing the Sybase log files. Refers to the directory for storing the Solaris log files. Refers to the directory for storing the backup files of dynamic data. Refers to the directory for storing the license file of the M2000. Refers to the directory for storing the SSO data files.
11-8
Issue 03 (2010-08-31)
Sun Fire V890 Disk Planning and Disk Array Planning (HA System)
In the HA system, the configuration of local disks on each server and the planning of disk partitions are the same. Each Sun Fire V890 server is configured with six 146 GB hard disks, two of which are partitioned according to Table 11-3. Table 11-3 Planning of the server disk partitions (HA, V890) Hard Disk No. 1 Partition No. 0 1 2 Partition Name / swap overlap Size (MB) 110000 20000 Description Root partition Data exchange partition Disk mapping. Retain the default size. Reserved Used for disk mirroring. You need not set the partition name and size. The system assigns the partition size automatically.
3 4 5 6 7
/globaldevices -
1024 10 to 260
Used as the mirrored disk for the first hard disk
Each Sun Fire V890 server is also configured with a 6140 disk array. Each 6140 disk array consists of sixteen 146 GB hard disks. Two disks are used for hot spares, and the remaining 14 disks are used for RAID5. Hot spares are used to replace the faulty disks when the disks on the disk array have faults. Two volumes are created on each 6140 disk array. For details on how to plan volumes on the disk array, see Table 11-4. Table 11-4 Planning for the 6140 disk array Disk Array No. 1 Volume Name oss_v0 oss_v1 2 Size (GB) 810 810
Used as the mirroring disk array for the first disk array
Issue 03 (2010-08-31)
11-9
Sun Fire E4900 Disk Planning and Disk Array Planning (HA System)
In the HA system, the configuration of local disks on each server and the planning of disk partitions are the same. Each Sun E4900 server is configured with two 146 GB hard disks, which are partitioned according to Table 11-5. Table 11-5 Planning of the server disk partitions (HA, E4900) Hard Disk No. 1 Partition No. 0 1 2 Partition Name / swap overlap Size (MB) 110000 20000 Description Root partition Data exchange partition Disk mapping. Retain the default size. Reserved Used for disk mirroring. You need not set the partition name and size. The system assigns the partition size automatically.
3 4 5 6 7
/globaldevices -
1024 10 to 260
Used as the mirrored disk for the first hard disk
Each Sun Fire V890 server is also configured with a 6140 disk array. Each 6140 disk array consists of sixteen 146 GB hard disks. Two disks are used for hot spares, and the remaining 14 disks are used for RAID5. Hot spares are used to replace the faulty disks when the disks on the disk array have faults. Two volumes are created on each 6140 disk array. For details on how to plan volumes on the disk array, see Table 11-6. Table 11-6 Planning for the 6140 disk array Disk Array No. 1 Volume Name oss_v0 oss_v1 2 Size (GB) 810 810
Used as the mirroring disk array for the first disk array
11-10
Issue 03 (2010-08-31)
Sun T5220 Disk Planning and Disk Array Planning (HA System)
In the HA system, the configuration and partition planning of the local hard disk on each server are the same. The T5220 system should be configured with four 146 GB hard disks and one S3100 or S2600 disk array. The S3100 disk array consists of 16 x 146 GB hard disks and the S2600 disk array consists of 12 x 450 GB hard disks. Two of the six hard disks are partitioned according to Table 11-7 while the other two are idle. Table 11-7 Disk partition planning of the T5220 server Hard Disk No. Partitio n No. 0 1 2 Partition Name / swap overlap Size (MB) 110000 20000 Description Root partition Swapping partition Used for disk mapping. Retain the default size. Reserved Used for disk mirroring. You need not set the partition name and size. The system assigns the partition size automatically.
3 4 1 5 6 7
/globaldevices -
1024 10 to 260
Used as the mirror disk of the first hard disk.
Each Sun T5220 server is configured with an S3100 disk array or an S2600 disk array.
l
Each S3100 disk array consists of sixteen disks. Two disks are used as hot spares and the other fourteen disks are used as two RAID5s. Hot spares are used to replace the faulty disks. Two volumes of the same size are created on the disk array. For details, see Table 11-8. Each S2600 disk array consists of twelve disks. Two disks are used as hot spare disk and the other ten disks are used as one RAID 10. Hot spares are used to replace the faulty disks. Three volumes of the same size are created on the disk array. For details, see Table 11-9.
Table 11-8 Planning for the S3100 disk array Disk Array No. 1
Issue 03 (2010-08-31)
Volume Name oss_v0
Size (GB) 810

11-11
Disk Array No.
Volume Name oss_v1
Size (GB) 810
Used as the mirrored disk array of the first disk array
Table 11-9 Planning for the S2600 disk array Disk Array No. 1 Volume Name oss_app0 oss_app1 oss_app2 2 Size (GB) 671 671 671
Sun M4000/M5000 Disk Planning and Disk Array Planning (HA System)
In the HA system, the configuration and partition planning of the local hard disk on each server are the same. The M4000/M5000 system should be configured with two 146 GB hard disks and one S3200/6140 or S2600 disk array. The S3200/6140 disk array consists of 16 x 146 GB hard disks and the S2600 disk array consists of 12 x 450 GB hard disks. The two local hard disks are partitioned according to Table 11-10. Table 11-10 Disk partition planning of the M4000/M5000 server Hard Disk No. Partitio n No. 0 1 2 1 3 4 5 6 /globaldevices 1024 Partition Name / swap overlap Size (MB) 110000 20000 Description Root partition Swapping partition Used for disk mapping. Retain the default size. Reserved
11-12
Issue 03 (2010-08-31)
Hard Disk No.
Partitio n No. 7
Partition Name -
Size (MB) 10 to 260
Description Used for disk mirroring. You need not set the partition name and size. The system assigns the partition size automatically.
Used as the mirror disk of the first hard disk.
Each Sun M4000/M5000 server is configured with an S3200/6140 disk array or an S2600 disk array.
l
Each S3200/6140 disk array consists of sixteen disks. Two disks are used as hot spares and the other fourteen disks are used as two RAID5s. Hot spares are used to replace the faulty disks. Two volumes of the same size are created on the disk array. For details, see Table 11-11. Each S2600 disk array consists of twelve disks. Two disks are used as hot spare disk and the other ten disks are used as one RAID 10. Hot spares are used to replace the faulty disks. Three volumes of the same size are created on the disk array. For details, see Table 11-12.
Table 11-11 Planning for the S3200/6140 disk array Disk Array No. 1 Volume Name oss_v0 oss_v1 2 Size (GB) 810 810
Table 11-12 Planning for the S2600 disk array Disk Array No. 1 Volume Name oss_app0 oss_app1 oss_app2 2 Size (GB) 671 671 671
Issue 03 (2010-08-31)
11-13
11.2.2 Viewing the Disk Usage of the M2000 Server Using Solaris Commands
This section describes how to use Solaris commands for viewing the disk usage of the M2000 server. This task uses very few system resources and does not affect the system operation.
Prerequisite
Log in to the server as user omcuser through SSH mode. In the HA system, log in to the two nodes.
Procedure
Step 1 Run the following command to viewing the disk usage of the M2000 server. -bash-3.00$ df -k The system displays the following information:
Filesystem /dev/dsk/c0t0d0s0 /proc fd /dev/dsk/c0t1d0s7 swap kbytes used avail capacity 2053605 997684 994313 51% 0 0 0 0% 0 0 0 0% 35009161 2562019 32097051 8% 3431792 6664 3425128 1% Mounted on / /proc /dev/fd /export/home /tmp
The command result contains the following information:

l l l l l l
File system name File size (unit: KB) Used space Free space Disk usage Capacity percentage of the filled file system and the mounting point
Normally, the disk usage is smaller than 90%, which means the value of capacity is smaller than 90% in the output. ----End
11.2.3 Clearing the Disk Space of the M2000 Server

This section describes how to clear the disk space of the M2000 server. Before clearing disk space, ensure that the files to be deleted are useless. Deleting a useful file by mistake may lead to a system failure.
Context
During the routine O&M, back up and clear the following files:
l l l
Files storing information about NEs and the M2000 server Software upgrade package and decompressed files Trace logs
11-14

l l
Backup files Temporary files created during the system operation
CAUTION
You can delete files when the server is running. Before deleting files, run the command ls -l to check the files generated on that day. Do not delete the files generated on the very day.
Procedure
l Export the files that save the information about NEs and the M2000 server. Back up the files on a tape. The files are divided into the following types:
Files generated during alarm auto-dump Alarm dump files are stored in the /export/home/omc/var/ThresholdExport/FM directory.
User log files User log dump files are stored in the /opt/OMC/var/userlogs directory. System generated core files Core files refer to the files in the /export/home/omc/var/logs/ directory. Trace history files Trace history files are stored in the /export/home/omc/var/logs/tracebak/ directory.
Delete the software upgrade package and the decompressed files. After the upgrade, delete the original upgrade package and the decompressed files. The upgrade package and decompressed files are stored in the folder named after the upgrade patch in the path /export/home.
CAUTION
Generally, the decompressed upgrade files are saved in the /export/home directory. The folder name of the upgrade files is created according to the upgrade patch name. The actual saving path may be different. For example, the saving folder may be in the /export/home/ bak directory. l Delete trace Logs. Modify the value of tracebackupnum in the tracemonitor_svc_ex.xml file to reduce the number of trace backup files. Edit the tracemonitor_svc_ex.xml file in the /opt/OMC/etc/conf/ directory to set the trace log monitor period, size limit, and number of backup files. /opt/OMC is the default installation path of the M2000 server software. The contents of the tracemonitor_svc_ex.xml file are as follows:
<?xml version="1.0" encoding="iso-8859-1"?>
Issue 03 (2010-08-31)
11-15
<tracemonitor name="tracemonitor" mount="/imap/common/tracemonitor"> <strategy name="imap">  <param name="checktracetime">300</param>  <param name="tracebackupnum">50</param> </strategy> <strategy name="other"> <filename name="tao.trace"> <param name="filesize">200</param> <param name="tracebackupnum">20</param> </filename> </strategy> </tracemonitor>
In checktracetime, you can set the trace log monitor period. The system checks the trace file at the regular interval of 300s. In tracebackupnum, you can set the number of backup trace files for each process in the /opt/OMC/var/logs/tracebak directory. For a process, if the number of trace file backups in the tracebak folder exceeds the preset value, the system automatically deletes the oldest trace files in sequence. l Clear the backup files.

After the upgrade, delete the backup files for the upgrade or copy them to tapes. Back up all the files in the /export/home/backup/omc directory to tapes.
Delete the files that are no longer in use. Before clearing disk space, ensure that the files to be deleted are no longer required. Deleting a useful file by mistake may lead to a system failure. 1. 2. 3. Choose Start > Program > iManager M2000 Client > M2000 Log Information Collector. In the displayed Log Information Collector dialog box, select Core files in server. Click Collect. Save the collected core files to the path C:\iManagerM2000Client\client\diagnosis \collected files. C:\iManagerM2000Client is the default installation path of the M2000 client software.
CAUTION
l
The M2000 log information collector collects the stack information from the core files. In addition to the stack information, the core files also include other information. Therefore, before deleting the core files, confirm the deletion with Huawei technical support engineers. Because the size of the core files is large, you must compress the core files before sending them.
4. 5. l
After sending all the core files and the stack files to Huawei for confirmation, delete the core files and stack files that are no longer required. Stop the M2000 server. Delete the files in the /var/tmp directory. Delete other files that are no longer in use. Log in to the M2000 server as user dbuser through SSH mode. Change to the Sybase installation directory.
Clear up disks regularly. 1. 2.
11-16
By default, the installation directory is /opt/sybase. -bash-3.00$ cd /opt/sybase 3. Run the environment variable. -bash-3.00$ . .profile 4. Access the Sybase database and run the following commands: -bash-3.00$ isql -Sdatabase server name -Usa -Ppassword of user sa 1> use omcdb 2> go 1> select fdn,neName from tbl_AllNeInfo 2> go
NOTE
5.
Switch to log in as user omcuser. 1> exit -bash-3.00$ su - omcuser Password: Password of omcuser
6.
Change to the directories /export/home/sysm/ftproot/CmSync/ and /export/home/ sysm/ftproot/pm/ to delete the folders of associated FDNs that are not listed in the database. -bash-3.00$ rm -r /export/home/sysm/ftproot/CmSync/neNE fdn -bash-3.00$ rm -r /export/home/sysm/ftproot/pm/neNE fdn
7.
Change to the /opt/OMC/var/med directory to delete the folders of associated FDNs that are not listed in the database. -bash-3.00$ rm -r /opt/OMC/var/med/neNE fdn
----End
Issue 03 (2010-08-31)
11-17
12 Backing Up and Restoring the M2000 (HA)
12
Context
Backing Up and Restoring the M2000 (HA)
About This Chapter

This chapter describes how to back up and restore the M2000 HA system.
Depending on the data to be backed up, three data backup solutions are provided for the M2000. Dynamic data backup: backs up the dynamic service data of the M2000 system. Static data backup: backs up the M2000 server application software, database application software, database device files, and M2000 configuration files on the hard disks of the M2000 server. System data backup: backs up the system data of the M2000 server, such as operating system data, database application data, M2000 server application data. Static data backup and system data backup are implemented by the Backup & Restore Tools (BRT). For details, see M2000 Backup and Restore Guide (BRT-Based, Sun). 12.1 M2000 Backup and Restore Solutions This section describes the backup scheme, backup strategy, and restore scenarios of M2000 dynamic data. 12.2 Backing Up and Restoring M2000 Dynamic Data (HA) This section describes how to back up and restore the dynamic data in the M2000 HA system.
Issue 03 (2010-08-31)
12-1
12.1 M2000 Backup and Restore Solutions

This section describes the backup scheme, backup strategy, and restore scenarios of M2000 dynamic data. 12.1.1 Backup of M2000 Dynamic Data This section describes the backup of the M2000 dynamic data. 12.1.2 Policies of M2000 Data Backup Based on the backup scenarios, rules for naming backup files, and rules for naming backup tapes, this describes how to back up the M2000 system. 12.1.3 Scenarios of M2000 Data Restoration This section describes the dynamic data restore for typical scenarios.
12.1.1 Backup of M2000 Dynamic Data

This section describes the backup of the M2000 dynamic data. Dynamic data backup refers to the backup of the M2000 dynamic service data. It is used to restore the history data when the M2000 is running properly or the static data restoration is complete. For details about the backup contents, backup modes, and storage media of the dynamic data backup, see Table 12-1. Table 12-1 Introduction to dynamic data backup Item Backup Contents Contents
l
Database data For details see 10.1 M2000 Database. M2000 system files Files under the /export/home/omc/var, /export/home/sysm/devdoc, and /export/home/sysm/ftproot directories.
CAUTION
l The configuration files related to the static data are stored in the /export/home/
omc/var directory. Thus, do not delete the directory and the files in the directory.
l If the PRS is not configured on the M2000 system, the sumdb database does not
exist.
l When backing up the M2000 system files, the system does not back up the log
files and Trace files in the previous directories.
You need to back up only the active node of the HA system.
12-2
Issue 03 (2010-08-31)
Item Backup modes
Contents Periodic backup After the periodic backup is activated, perform the periodic backup once every day. Perform the full backup on the specified day of each week. On the other six days, automatically perform incremental backup at the same time. After a new round of periodic backup is performed, all the backup files of the previous round are deleted automatically.
NOTE Backing up dynamic data consumes system resources. Thus, the time set for backup should be at night when the system traffic is light.
Manual backup
Full backup: backs up all the dynamic data. When a new full backup is performed, all the backup files in the backup directory are deleted automatically. Perform full backup according to your requirements. Incremental backup: backs up the dynamic data that has changed since the last full backup. The incremental backup is saved in another file, without overwriting the file of full backup. Perform incremental backup according to your requirements.
Storage device
l l l l
Tape Hard disk Tape and hard disk Storage device of the NetBackup server When storage media is the hard disk in the M2000 server, the directory of the backup files is: /export/home/backup/omc. When storage media is the tapes in the M2000, the directory of backup files is:/dev/rmt/0.
CAUTION If a system has more than one tape drives, the directory of the backup files is the same as that of the tape drive, which is specified when backing up dynamic data on a tape.
The directory of backup files
When storage media is the hard disk in the NetBackup server, the directory of the backup files is: /export/home/backup/omc.
CAUTION Dynamic data of the M2000 is backed up to the directory:/export/home/ backup/omc. Then the system automatically packs the backup data and moves the backup data to the storage media on the NetBackup server.
After the backup is performed, the backup contents are automatically packaged as a backup file. For details about how to name a backup file, see Rules for Naming Backup Files of Dynamic Data.
Issue 03 (2010-08-31)
12-3

NOTE
When the M2000 system performs the dynamic data backup, do not perform operations such as modifying the configuration database.
12.1.2 Policies of M2000 Data Backup

Based on the backup scenarios, rules for naming backup files, and rules for naming backup tapes, this describes how to back up the M2000 system.
Typical Scenarios for M2000 Data Backup

Dynamic data backup is applicable to routine maintenance.
Rules for Naming Backup Files of Dynamic Data

When backing up the static data, name the backup files in the following format: /export/home/ backup/omc/*-YYYYMMDDhhmmss.tar, where, * indicates all for full backup or inc for incremental backup. For example:
l
The file name all-20040601042002.tar refers to a full backup file generated on 2004-06-01 04:20:02. The file name inc-20040602042001.tar refers to an incremental backup file generated on 2004-06-02 04:20:01.
NOTE
l l
The latest backup information is recorded in the /export/home/backup/omc/backup.log file. During the backup process, the inc-YYYYMMDDhhmmss or all-YYYYMMDDhhmmss folder is generated in the /export/home/backup/omc path for storing backup files. When the backup is complete, the folder is packed as the inc-YYYYMMDDhhmmss.tar or allYYYYMMDDhhmmss.tar file, and the inc-YYYYMMDDhhmmss or all-YYYYMMDDhhmmss folder is automatically deleted.
Rules for Naming the Tapes That Store the Backup Data
The rule for naming a backup tape is as follows: *backup tape (backup date). The character * stands for the following data:
l l l
Dynamic data Static data Data of the operating system
For example, if a tape is labeled "static data backup tape (2007-11-28)", it indicates that the static data backup is performed on November 28, 2007.
12.1.3 Scenarios of M2000 Data Restoration

This section describes the dynamic data restore for typical scenarios. The M2000 system runs normally or the static data restoration is complete. It needs to roll back to the historical operational status such as the operational status of the last week.
12.2 Backing Up and Restoring M2000 Dynamic Data (HA)

This section describes how to back up and restore the dynamic data in the M2000 HA system. 12.2.1 Setting a Storage Device of Backup Data Through the Client (HA) This section describes how to set a storage device of backup data through the client. 12.2.2 Periodically Backing Up the M2000 Dynamic Data (HA) This section describes how to periodically back up the M2000 dynamic data. 12.2.3 Manually Backing Up the M2000 Dynamic Data (HA) This section describes how to manually back up the M2000 dynamic data. 12.2.4 Restoring the M2000 Dynamic Data (HA) This section describes how to restore the dynamic data of the M2000 HA system.
12.2.1 Setting a Storage Device of Backup Data Through the Client (HA)
This section describes how to set a storage device of backup data through the client.
Prerequisite
l l
The M2000 server is running properly. The connection between the M2000 client and the M2000 server is normal.
Context
You can set the storage device of backup data when the M2000 services are running. The storage devices are as follows:
l
Disk The backup files of the dynamic data are stored on a hard disk. Tape or Disk and Tape Tapes are not easy for future management, and therefore do not use Tape or Disk and Tape as a storage device. To copy the dynamic data to a tape, you need to manually copy the backup data from the hard disk to a tape after the dynamic data is backed up on a hard disk. For details, see 16.3.4 How Do I Copy the Backup Dynamic Data from a Hard Disk to a Tape (HA, Sun).
Veritas Veritas refers to the storage device of the NetBackup server. If a storage device is set to Veritas, the system automatically packs the backup data and moves the backup data to the storage device of the NetBackup server. Then, the M2000 server does not keep any backup data.
Issue 03 (2010-08-31)
12-5
CAUTION
l l l
Do not modify the configuration files of a storage device when the backup is in process. Do not replace a storage device when the backup is in process. To prevent the dynamic data backup files that are stored on a local hard disk from missing, you are advised to select Veritas for data backup.
Procedure
Step 1 Start the M2000 client and log in to the M2000 server. Step 2 Click Maintenance > Backup Management > System Backup. The System Backup interface is displayed, as shown in Figure 12-1. Figure 12-1 Setting a storage device (I)
Step 3 Click Reset. Select a storage device in the displayed Medium Type Setting dialog box, and then click OK, as shown in Figure 12-2. Figure 12-2 Setting a storage device (II)
Step 4 The Confirm dialog box is displayed, prompting you for a full backup after you change the storage device. Click Yes.
Step 5 When the storage device is changed, the Message dialog box is displayed. Click OK. Step 6 Perform a full backup. For details, see 12.2.3 Manually Backing Up the M2000 Dynamic Data (HA). ----End
12.2.2 Periodically Backing Up the M2000 Dynamic Data (HA)

This section describes how to periodically back up the M2000 dynamic data.
Prerequisite
l l l
You have logged in to the M2000 client. You are authorized to perform relevant operations. The tape drive is connected properly, and it holds a tape if you plan to back up data on the tape. A hard disk has sufficient free space if you plan to back up data on the hard disk.
Context
Generally, the M2000 dynamic data is backed up periodically. The periodic backup of the dynamic data is performed in full backup mode.In an HA system, if you want to copy the dynamic data to a tape, it is recommended that you manually copy the backup data from the hard disk to a tape after the dynamic data is backed up on a hard disk. For details, see 16.3.4 How Do I Copy the Backup Dynamic Data from a Hard Disk to a Tape (HA, Sun).
NOTE
The time required for backing up M2000 dynamic data is related to the actual environment. Generally, it takes about five hours. Do not suspend a periodic backup task. The reasons are as follows:
l l
Procedure
Step 1 On the main window, choose Maintenance > Task Management. The Task Management dialog box is displayed. Step 2 Choose Task Type > Backup > Server Backup from the navigation tree, and then double-click the Server Backup node. The Attribute dialog box is displayed, as shown in Figure 12-3.
Issue 03 (2010-08-31)
12-7
12-8
Issue 03 (2010-08-31)
12.2.3 Manually Backing Up the M2000 Dynamic Data (HA)

This section describes how to manually back up the M2000 dynamic data.
Prerequisite
l l l
You have logged in to the M2000 client. You are authorized with the relevant operation rights. The tape drive is connected properly, and it holds a tape if you plan to back up data on the tape. A hard disk has sufficient free space if you plan to back up data on the hard disk.
Context
l
Manual backup is required in special or emergency situations such as the loss of backup tapes and the failure of the M2000 system. Manual backup can be full backup or incremental backup.
Issue 03 (2010-08-31)

l
In an HA system, if you want to copy the dynamic data to a tape, it is recommended that you manually copy the backup data from the hard disk to a tape after the dynamic data is backed up on a hard disk. For details, see 16.3.4 How Do I Copy the Backup Dynamic Data from a Hard Disk to a Tape (HA, Sun).
NOTE
The time required for backing up M2000 dynamic data is related to the actual environment. Generally, it takes about five hours.
Procedure
Step 1 In the main window, choose Maintenance > Backup Management > System Backup. The System Backup dialog box is displayed. Figure 12-5 Manual backup
If Backup Medium in Figure 12-5 does not meet the actual requirement, you can click Reset to change the backup medium before data backup. For details, see 12.2.1 Setting a Storage Device of Backup Data Through the Client (HA). Step 2 In the System Backup dialog box shown in Figure 12-5, click Full Backup to perform full backup. Click Incremental Backup to perform incremental backup. If the Status displays Succeeded, you can infer that the backup is successful.
NOTE
Full backup must be performed before incremental backup. Incremental backup must be performed based on full backup.
----End
12.2.4 Restoring the M2000 Dynamic Data (HA)

This section describes how to restore the dynamic data of the M2000 HA system.
Prerequisite
l
You have logged in to the active node as user root through SSH mode by using the corresponding IP address. You have obtained the backup files for restoring the dynamic data. The Sybase database service is running properly on the active node.
l l
Context
You can restore the M2000 based on the latest full backup and incremental backup files. After you restore the M2000, all the contents in the backup file package are restored. If certain data generated after the backup start time, such as the NE performance data or alarm data, is not compressed in the backup file package, the M2000 enables the automatic synchronization function to obtain data from NEs and process the data. During the restoration of the dynamic data, the M2000 services are stopped, and thus the performance data and alarm data of the managed NEs cannot be processed. After the dynamic data is backed up, the dynamic data backup package is generated on the hard disk. You can copy the backup package to tapes. In this case, you need to copy the backup data to the hard disk before you restore the dynamic data. For details, see 16.3.5 How Do I Copy the Backup Dynamic Data from a Tape to a Hard Disk (HA, Sun).
NOTE
The time required for restoring M2000 dynamic data is related to the actual environment. Generally, it takes about six hours.
Procedure
Step 1 Perform the following operations on the active node to restore the M2000 data: 1. Decompress the backup file that stores the to-be-restored dynamic data. # cd /export/home/backup/omc # tar xf backup file that stores dynamic data For example, if you need to restore the full backup file generated on 18:06:22 2008-01-30, decompress the relevant package. # tar xf all-20080130180622.tar
NOTE
You need to decompress the relevant package regardless of the full backup file or the incremental backup file that is to be restored. For example, there are two packages available: all-20080130180622.tar and inc-20080131180622.tar. If you need to restore the system to the history operational status of 18:06:22 2008-01-30, decompress all-20080130180622.tar. If you need to restore the system to the history operational status of 18:06:22 2008-01-31, you need to decompress only inc-20080131180622.tar. You need not decompress all-20080130180622.tar.
2.
Navigate to the path after the decompression. # cd name of the backup file that stores dynamic data For example: # cd all-20080130180622
Issue 03 (2010-08-31)
12-11
3.
Run the following script to restore dynamic data: # ./restore.sh
4.
When the system displays the following message, type the password of user sa of the database.
Note: Enter q/Q to exit this tool. Please input the supperuser's password of database[default:emsems]:
NOTE
You can type q or Q to quit the script.
5.
When the system displays the following message, type 1 to start restoring dynamic data. Please make a choice[1-2]:
NOTE
Restoring data takes a long time. Wait with patience.
After the restoration is complete, the system displays Operation succeeds.
CAUTION
If you have rebuilt the user database by using the BRT before restoring the dynamic data, you need to set the parameters of the user database by referring to the BRT backup and restore guide and then start the M2000 services. The reason of the previous operation is that the direct startup of the M2000 services may fail because the parameters of the rebuilt M2000 database are not set. Step 2 Run the following command on the active node to start the M2000 services: # . /opt/OMC/svc_profile.sh # cd /opt/OMC/tools/common # ./commonop.sh -ostartsvc
l
If the system displays the following information, you can infer that the M2000 service is started. In such a case, proceed with Step 3 and Step 4.
Operation succeeds
If the system displays the following information, you can infer that the M2000 service fails to be started. In such a case, do not proceed with Step 3 or Step 4. Instead, contact Huawei technical support engineers for assistance.
Performing Start OMC services failed
NOTE
Starting the M2000 service takes a long time. Wait with patience.
Step 3 Run the following command on the standby node to check whether there is any system output: # . /opt/OMC/svc_profile.sh # daem_ps
l
If there is any system output, you can infer that the daem process is started.
12-12

l
If there is no system output, you can infer that the daem process is not started. Run the following commands to start it: # start_daem -type standby
Step 4 Run the following commands on the active node to delete the decompressed backup files: # cd /export/home/backup/omc # rm -rf directory for storing the decompressed backup files For example: # rm -rf all-20080130180622 ----End
Issue 03 (2010-08-31)
12-13
13 M2000 Routine Maintenance (HA)
13
M2000 Routine Maintenance (HA)
About This Chapter

This chapter lists the maintenance items and provides guidance for the routine maintenance of the M2000 HA system. You can add or delete the maintenance items based on requirements. 13.1 M2000 Routine Maintenance Items (HA) This section describes the recommended maintenance items of the M2000 HA system. 13.2 Daily Maintenance Operations (HA) This section describes the daily maintenance operations that need to be performed on the M2000 HA system. 13.3 Weekly Maintenance Operations (HA) This section describes the weekly maintenance operations that need to be performed on the M2000 HA system. 13.4 Monthly Maintenance Operations (HA) This section describes the monthly maintenance operations that need to be performed on the M2000 HA system.
Issue 03 (2010-08-31)
13-1
13.1 M2000 Routine Maintenance Items (HA)

This section describes the recommended maintenance items of the M2000 HA system. Table 13-1 lists the recommended maintenance items of the M2000. You can add or delete maintenance items according to the actual requirement. Table 13-1 List of maintenance items No. Item Mainten ance Period Daily Daily Reference
1 2
Check the cluster status. Check the status of performance measurement. Check the loss of performance results. Check the status of alarm reception. Check the status of the NMS connection. Check the status of the alarm box. Check OMC alarms or events. Check the connection between the M2000 and NEs. Check the M2000 logs. Check the error logs of the Solaris operating system. Check the hard disk usage of the M2000 server. Check the status of the M2000 database. Check the M2000 services (HA).
The cluster status is normal. All measurement counters and measurement objects are being measured. No performance result is lost. The alarms reported by NEs are received in real time. The NMS can collect the alarms and performance data reported by the M2000. The alarm box can report the M2000 alarms in real time. No OMC alarm or event is generated. The connection between the M2000 and NEs is normal. The system runs properly. No abnormal or malicious operations are performed. No error log is generated. The usage of each disk is less than 90%. The database runs properly and its usage is less than 80%. All the services run properly, and no service is in not running state.
3 4 5
Daily Daily Daily
6 7 8
Daily Daily Daily
9 10 11 12 13
Daily Daily Daily Daily Daily
13-2
Issue 03 (2010-08-31)
No.
Item
Mainten ance Period Daily Daily Daily Weekly
Reference
14 15 16 17
Check the core file of the server. Check the hardware of the M2000 server. Check the results collected by the SMC. Check the configuration of alarm timing tasks.
No core file exists in the /export/home/ omc/var/logs directory. The hardware of the M2000 server is not damaged. The operating environment of the M2000 server is normal. The time of alarm timing tasks is set properly. This prevents the time conflict with background tasks. The conflict may result in heavy CPU load. The time of automatic log dump is set properly. This prevents the time conflict with background tasks. The conflict may result in heavy CPU load. The time of NE log synchronization is set properly. This prevents the time conflict with background tasks. The conflict may result in heavy CPU load. The file server is configured properly. The time for automatically and periodically backing up the M2000 server and NEs is set properly. Backup files are generated in disks. The threshold of system monitoring is set properly. The time of NE configuration synchronization is set properly. The number of equivalent NEs managed by the M2000 does not exceed the management capability of the M2000. The corresponding startup files exist in the /etc/rc2.d directory. Back up the M2000 database and system files. View the backup files on disks and tapes. The time of the M2000 server is correct.
18
Check the configuration of automatic log dump.
Weekly
19
Check the configuration of NE log synchronization time. Check the configuration of the file server. Check the configuration of the system backup.
Weekly
20 21
Weekly Weekly
22 23
Check the configuration of system monitoring. Check the configuration of NE configuration synchronization time. Check the management capability of the M2000. Check the status of the M2000 routes. Back up the M2000.
Weekly Weekly
24
Weekly
25 26
Weekly Weekly
27
Check the time of the M2000 server.
Weekly
Issue 03 (2010-08-31)
13-3
No.
Item
Mainten ance Period Weekly
Reference
28
Check the disk status of the M2000.
All the disks that are in use are online, the KSTATE columns of pl, sd, and v are ENABLED, and the STATE columns are ACTIVE. The usage of each partition is less than 80%. The power supply is normal. For details about how to check the CDROM drive and the tape drive, refer to the Solaris Administrator Guide. The timeout for stopping the M2000 application resources is set correctly. The trust between two servers in an HA system is normal. The version number of the Sun Cluster software is the same on both nodes. Both the active and standby nodes can identify the shared disk. The active/standby relation of the logical host of the HA system is normal. The right and owner of the /opt/ SUNWscsyb/bin/sybase_stop_servers file are set correctly. The disk array is not damaged.
29 30
Check the power supply of the M2000 server. Check the peripherals of the M2000 server. Check the timeout for stopping the M2000 application resources. Check the trust between two servers in an HA system. Check the version of the Sun Cluster software. Check the global devices of an HA system.
Monthly Monthly
31
Monthly
32 33 34 35 36
Monthly Monthly Monthly
Check the logical host of an Monthly HA system. Check the right and owner of the /opt/SUNWscsyb/ bin/sybase_stop_servers file. Check the front panel of a disk array. Monthly
37
Monthly
For details about how to operate and maintain NEs, see the M2000 Online Help.
13.2 Daily Maintenance Operations (HA)

This section describes the daily maintenance operations that need to be performed on the M2000 HA system. 13.2.1 Checking the Cluster Status (HA) This section describes how to check the cluster status. Checking the cluster status enables you to ensure that the Cluster runs properly. 13.2.2 Checking the Status of Performance Measurement
This section describes how to check the performance measurement state. You must ensure that all the required measurement counters and measurement objects are in proper status. 13.2.3 Checking the Missing Performance Result To ensure that no result is lost, you must check that the missing performance result exists. 13.2.4 Checking the Alarm Reception Check the alarm reception and ensure that the M2000 can receive alarms from NEs in real time. 13.2.5 Checking the NMS Connection This section describes how to check the NMS connection and to ensure that the NMS connection is normal. 13.2.6 Checking the Functionality of Alarm Box Check the function of generating visual and audible alarms for the alarm box and ensure that the alarm box can indicate the alarms on the M2000 in real time. 13.2.7 Checking the Owner of the M2000 File System This section describes how to check the owner of the M2000 file system. You need to check the owner of the M2000 file system regularly to ensure proper user operations because some tools or operations may change the owner of the M2000 file system.You need to perform this operation on both node 1 and node 2. 13.2.8 Check OMC Alarms/Events This section describes how to check whether the M2000 system is normal. This section also describes how to check whether the alarms and events of the M2000 are generated. 13.2.9 Checking Connections Between the M2000 and NEs This section describes how to check the connections between the M2000 and NEs. 13.2.10 Checking M2000 Logs M2000 user logs record the details about user operations, such as user name, start time, end time, and log type. The M2000 system administrators and operators can query user logs. 13.2.11 Checking the Error Log of the Solaris This section describes how to check the error logs of the Solaris operating system. 13.2.12 Checking the Disk Usage of the M2000 Server This section describes how to check the disk usage and clean up the expired log files, temporary files, and other files that are no longer in use. This operation requires very few system resources and does not affect the system operation. 13.2.13 Checking the States of M2000 Databases This section describes how to check the states of the M2000 database services, database states, and database usage. This operation requires only a few system resources and does not affect the system operation. 13.2.14 Checking the States of M2000 Services This section describes how to check the states of M2000 services. This operation requires very few system resources and does not affect system operation. 13.2.15 Checking the Core Files on the Server This section describes how to check the /export/home/omc/var/logs directory and to ensure that core files do not exist. 13.2.16 Checking the Hardware of the M2000 Server This section describes how to check the M2000 server hardware. 13.2.17 Checking the SMC Collection Results
This section describes how to check the SMC collection results and to ensure that the M2000 server environment is normal.
13.2.1 Checking the Cluster Status (HA)

This section describes how to check the cluster status. Checking the cluster status enables you to ensure that the Cluster runs properly.
Prerequisite
Log in to the active or standby node as user root through SSH mode.
Procedure
Step 1 Run the scstat command. # scstat Step 2 Check the command result. Ensure that the status of the cluster is normal. The command result is listed in Table 13-2. Table 13-2 Result of the scstat command Parameter Cluster Nodes Cluster Transport Paths
Quorum Votes by Node
Description of the Command Result Both nodes are online. Two Transport paths are available, and both are online. Both nodes are online. The device status is online. The active server configured in ossdg is the active node, and the backup server is the backup node. The ossdg device group is online. The oss_rg resource group includes: osssvr,ossdg_rs, sybase_rs, and ossapp_rs. The oss_rg is online on the active node, and offline on the backup node. All resources are online on the active node, and offline on the backup node.
Quorum Votes by Device Device Group Servers Device Group Status Resource Groups and Resources Resource Groups Resources
If the system is configured with a tape drive, rmt/1 and rmt/2 are displayed and both are offline.
----End
13.2.2 Checking the Status of Performance Measurement

This section describes how to check the performance measurement state. You must ensure that all the required measurement counters and measurement objects are in proper status.
Prerequisite
l l
You have logged in to the M2000 client. You are authorized to perform performance management.
Procedure
Step 1 Choose Performance > Measurement Management. The Measurement Management window is displayed. Step 2 Ensure that all the required measurement counters and the measurement objects on the Measurement Status tab page are in proper status. If there is any exception, contact Huawei technical support engineers for assistance. ----End
13.2.3 Checking the Missing Performance Result

To ensure that no result is lost, you must check that the missing performance result exists.
Prerequisite
l l
You have logged in to the M2000. You are authorized to perform performance management.
Procedure
Step 1 Choose Performance > Measurement Management. Step 2 From the navigation tree of the Measurement Status tab page, right-click a node and then choose Missing Result from the shortcut menu. Step 3 In the displayed Query Missing Result dialog box, set the related parameters. Default end time = Current time. Default start time = Current time - Time range of the missing results in the preference settings. Step 4 Click OK. Any measurement result that is missing within the time range is listed in a table in the displayed dialog box. The first column of the table displays the object information. The second column displays the corresponding time range. ----End
Postrequisite
If missing measurement results exist, synchronize the results.
1. 2. 3. 4.
Right-click a node in the navigation tree, and then choose Missing Result from the shortcut menu. In the Query Missing Result window, select an NE and a function subset whose missing results you want to query, and then click OK. In the dialog box of missing results, click Synchronize Result. In the Prompt dialog box, click OK. After the synchronization command is issued to the NE, it takes some time for the NE to report the performance measurement data. You can check whether the data is successfully reported by viewing whether the missing results disappear.
13.2.4 Checking the Alarm Reception

Check the alarm reception and ensure that the M2000 can receive alarms from NEs in real time.
Prerequisite
l l
You have logged in to the M2000 . You are authorized to perform fault management.
Procedure
Step 1 Choose Monitor > Browse Alarm List. The Filter window is displayed. Step 2 Set filter condition, then click OK. Step 3 Ensure that the M2000 can receive the alarms reported by NEs in real time. ----End
13.2.5 Checking the NMS Connection

This section describes how to check the NMS connection and to ensure that the NMS connection is normal.
Procedure
Step 1 Ensure that the NMS can collect the alarms and performance data reported from the M2000 . ----End
13.2.6 Checking the Functionality of Alarm Box

Check the function of generating visual and audible alarms for the alarm box and ensure that the alarm box can indicate the alarms on the M2000 in real time.
Prerequisite
l l
You have logged in to the M2000 . You are authorized to perform fault management.
13-8
Procedure
Step 1 Choose Monitor > Alarm Setting > Options. The Alarm Option window is displayed. Step 2 View the settings. Ensure that alarms generated from the NEs, which satisfy the conditions, can be indicated on the alarm box in real time. ----End
13.2.7 Checking the Owner of the M2000 File System

This section describes how to check the owner of the M2000 file system. You need to check the owner of the M2000 file system regularly to ensure proper user operations because some tools or operations may change the owner of the M2000 file system.You need to perform this operation on both node 1 and node 2.
Prerequisite
Log in to the M2000 server as user root through SSH mode.
Procedure
Step 1 Run the following commands to check whether the owner of the M2000 file system is correct: # . /opt/OMC/svc_profile.sh # . /opt/OMC/lbin/checkOSSRight.sh If the system output contains the information like Error, run the . /tmp/modifyRight.sh command to resume the owner of the M2000 file system.
Error: The rights of some OSS files are set incorrectly! You can execute the /tmp/modifyRight.sh script to correct the settings.
If the system output contains the information like OK, you can infer that the owner of the M2000 file system is correct.
OK: No rights of OSS files are assigned to user root.
----End
13.2.8 Check OMC Alarms/Events

This section describes how to check whether the M2000 system is normal. This section also describes how to check whether the alarms and events of the M2000 are generated.
Prerequisite
l l
You have logged in to the M2000 client. You are authorized to query alarms and events.
Procedure
Step 1 Check whether the OMC icon is colored or an alarm is displayed on it in the topology view.
If the system is operational, no alarm is generated. That is, the OMC icon is not colored or no alarm balloon is displayed. Step 2 Right-click the OMC icon, and then choose Query Alarm/Event > Alarm List. The Browse Alarm List window is displayed.
l
If the alarms listed in Table 13-3 are generated, handle the alarms immediately. Table 13-3 Alarms that need to be handled immediately Alarm Name The OMC Service Is Terminated Abnormally The Disk Usage Is Too High (Critical) Power Failure Fan Failure CPU Temperature Is Abnormal Hard Disk Failure Disk Array Failure Power or Fan Failure To the Disk Array Cabinet Failure To the Devices in the Disk Array Cabinet A Disk on the Array Is Faulty Memory Failure CPU Failure The Cache for the Array Controller Is Faulty Logical Drive Is Offline Array Reconstruction Error Physical Hard Disk Failed Hard Disk Synchronization Error The Temperature of the Disk Cabinet Is Abnormal Fan Failure In The Disk Cabinet Disk Cabinet Power Failed Array Reconstruction Reconstruct The Virtual Disk Disk Cabinet Failure Disk Physical State Is Changed Alarm ID 4 37 101 102 103 104 105 106 107 108 110 112 202 203 204 205 206 207 208 209 210 212 214 215
13-10
Issue 03 (2010-08-31)
Alarm Name Host Power Failure Host Power Cable Failure Host Temperature Is Abnormal Host Fan Is Abnormal
Alarm ID 217 218 219 220
If the alarms listed in Table 13-4 are generated, you need to clear them within one day. Table 13-4 Alarms that need to be handled within one day Alarm Name NE Mediation Layer Version Unmatched Insufficient Free Space of the Performance Database License Invalid License Expired License On Trail Server Backup Unsuccessful Alarm ID 303 405 501 505 506 512
During network expansion, multiple alarms listed in Table 13-5 are generated. In such a case, you can export the alarm statistical files every day and check the information in the Location Information column in the exported files. If the alarms are generated on the required NEs, you need clear the alarms. Table 13-5 Alarms to be focused on during network expansion Alarm Name NE Is Disconnected Alarm ID 301
If the alarms listed in Table 13-6 are generated many times, you need to locate the user who has not obtained the M2000 login password and tries to log in to the M2000 to prevent malicious operations. Table 13-6 Alarms about malicious operations Alarm Name The Number of Login Attempts Reaches the Maximum Alarm ID 11
Step 3 Right-click the OMC icon, and then choose Query Alarm/Event > Event Logs from the shortcut menu.
The Query Event Logs window is displayed.

l
If the events listed in Table 13-7 occur, you need to handle the events immediately. Table 13-7 Events that need to be handled immediately Event Name The Battery for the Array Controller Is Faulty Array Disk Is Offline Disk Logical State Is Changed Event ID 201 213 216
If the events listed in Table 13-8 occur, you need to handle them within one day. Table 13-8 Events that need to be handled within one day Event Name SMC Alarm Event ID 1099
During network expansion, multiple events listed in Table 13-9 occur. In such a case, you can export the event statistical files every day and check the information in the Location Information column in the exported files. If the events occur on the required NEs, you need to handle them. Table 13-9 Events that need to be focused on during network expansion Event Name Performance Result Loss Event ID 407
----End
Postrequisite
To handle alarms and events, perform the following steps: 1. 2. In the Browse Alarm List or Query Event Logs window, select a specific alarm or event. In the Process Advice area, click Click here to show detail Information. Then, you can obtain the detailed information and troubleshooting suggestions from the displayed alarm or event online help. (Optional) When handling alarms, you also need to acknowledge uncleared alarms, and analyze and acknowledge the alarms that are automatically cleared. The acknowledged and cleared alarms do not exist in the window any longer. The cleared but not acknowledged alarms are displayed in a different color. 4. 5. 6. Double-click an alarm or event. The Detail Information dialog box is displayed. In the Experience area, click Modify. The Experience dialog box is displayed. In the Modify Experience dialog box, type the information such as the symptom, cause, and recommended handling advice.
3.
13-12
The typed information is saved in the Experience area. 7. 8. Repeat 1 to 6 to handle each alarm or event. Ensure that the M2000 system is operational. No alarms or events occur if the M2000 system is operational.
13.2.9 Checking Connections Between the M2000 and NEs

This section describes how to check the connections between the M2000 and NEs.
Prerequisite
Before checking connections between the M2000 and NEs, ensure that:
l l
You have logged in to the M2000 . You are authorized to query the status of NE connections.
NOTE
The connection status of virtual NEs and the OMC (M2000 ) is NA (not applicable).
Procedure
Step 1 Choose System > NE Monitor. The NE Monitor dialog box is displayed. You can check the connection status of NEs. There are three connection status: Connected, Break, and NA. Step 2 Handle exceptions. For the Break status, you must obtain and analyze system information in time and solve the problem. The NA status is caused by an unmatched NE version. Check the NE version and then install the adaptation layer. For details, refer to the M2000 Commissioning Guide. Step 3 Check whether the NEs are connected correctly. The status of all NEs is Connected. ----End
13.2.10 Checking M2000 Logs

M2000 user logs record the details about user operations, such as user name, start time, end time, and log type. The M2000 system administrators and operators can query user logs.
Prerequisite
l l
You have logged in to the M2000 . You are authorized to check M2000 logs.
Procedure
Step 1 Choose System > Log Management > Query Operation Logs.
The Query Operation Logs window is displayed. By default, the system opens the Filter window automatically. Step 2 Set query conditions in the Filter window and click OK. User logs can be queried based on users, operations, terminals, time ranges, results, or objects. The queried results are displayed. Step 3 Handle abnormal operations. Handle the abnormal or unfriendly operations. For example, if a user fails to log in to the client for several times, perform the validity check for the user. Step 4 Confirm that no error information exists in M2000 logs. The system works properly. No abnormal or unfriendly operations are performed. ----End
13.2.11 Checking the Error Log of the Solaris

This section describes how to check the error logs of the Solaris operating system.
Prerequisite
Before checking error logs of the Solaris, ensure that you have logged in to the M2000 server as user omcuser through SSH mode.
Context
l
Viewing the Solaris error logs occupies few system resources and does not affect system operation. The record format of the /var/adm/messages file and the /var/log/syslog file is as follows: date and time-hostname-description
NOTE
The /var/adm/messages file is the core system log file. It contains the boot information about system startup and other status information about system operation. The /var/log/syslog file records the messages exported to the system console and the messaged generated by the syslog system service.
l
Generally, the messages such as err or failed are not displayed. If such messages are displayed, contact Huawei technical support engineers for assistance.
Procedure
Step 1 Open the /var/adm/messages file. -bash-3.00$ cd /var/adm -bash-3.00$ more messages Step 2 Check the file for error information. Step 3 Open the /var/log/syslog file. -bash-3.00$ cd /var/log
-bash-3.00$ more syslog Step 4 Check the file for error information. ----End
13.2.12 Checking the Disk Usage of the M2000 Server

This section describes how to check the disk usage and clean up the expired log files, temporary files, and other files that are no longer in use. This operation requires very few system resources and does not affect the system operation.
Prerequisite
l l
You have logged in to the M2000 system. You have the relevant operation privileges.
Procedure
Step 1 Choose Monitor > System Monitor > Monitor Browser. The System Monitor Browser window is displayed. Step 2 Click the Hard Disk Monitor tab. The disk usage of the M2000 server is displayed.
l l
The disk usage is smaller than 90%. View the partition with the largest remaining space. The remaining space must be sufficient to back up the M2000.
Step 3 Handle exceptional situations. Clear the disk space if the disk space is insufficient. For details, refer to 11.2.3 Clearing the Disk Space of the M2000 Server. Step 4 Check whether the disk usage of the M2000 server is within the normal range. ----End
13.2.13 Checking the States of M2000 Databases

This section describes how to check the states of the M2000 database services, database states, and database usage. This operation requires only a few system resources and does not affect the system operation.
Prerequisite
l l
You have logged in to the M2000 client. You have the relevant operation privileges.
Procedure
Step 1 Choose Monitor > System Monitor > Monitor Browser. The System Monitor Browser window is displayed. Step 2 Click the Database Monitor tab.
The information about the database of the M2000 server is displayed. Step 3 Handle exceptional situations. If the database usage is greater than 90%, clear some data space by dumping alarm data and user logs. The clearing operation does not affect the system operation. For details on how to clear a database, refer to 10.3 Clearing M2000 Databases. Step 4 Ensure that the database works properly. The database usage is smaller than 90%. ----End
13.2.14 Checking the States of M2000 Services

This section describes how to check the states of M2000 services. This operation requires very few system resources and does not affect system operation.
Prerequisite
l l
You have logged in to the M2000 client. You have the relevant operation privileges.
Procedure
Step 1 Choose Monitor > System Monitor > Monitor Browser. The Monitor Browser window is displayed. Step 2 Click the Service Monitor or Monitor Browser tab to monitor the processes running on the M2000 server. Step 3 Handle exceptional situations. If an process is suspended or abnormal, you should log in to the M2000 server as user root, stop it using kill_svc. If a service or process is inactive, start the service or the process using scswitch -e -j ossapp_rs. Step 4 Check whether the M2000 works properly. The Status of all M2000 services is Running. ----End
13.2.15 Checking the Core Files on the Server

This section describes how to check the /export/home/omc/var/logs directory and to ensure that core files do not exist.
Prerequisite
Log in to the server as user omcuser through SSH mode.
Procedure
Step 1 Go to the /export/home/omc/var/logs directory.
-bash-3.00$ cd /export/home/omc/var/logs Step 2 Check the /export/home/omc/var/logs directory and ensure that core files do not exist. -bash-3.00$ ls -ltr core* The core files are sorted by time. The file at the top is the earliest one. Delete the core files generated one week earlier. Contact Huawei technical support engineers to deal with the core files generated within the week. ----End
13.2.16 Checking the Hardware of the M2000 Server

This section describes how to check the M2000 server hardware.
Prerequisite
The cables are connected correctly. The M2000 server is switched on.
Procedure
Step 1 Check the server model.
NOTE
You can also run the prtdiag command to view the server type, which is contained in the system output.
Step 2 Check the server hardware based on the server model according to the delivery-attached manual of the server. The server works properly. The indicators are displayed properly. Step 3 If a disk array is used, check the disk array model. Then, check the hardware according to the manual mapping to the model of disk array. Step 4 Handle exceptional situations. If the hardware incurs a fault, locate the fault by referring to related manuals of the disk array and the server. For a fault difficult to locate, contact the engineers at Sun Microsystems. Step 5 Ensure that the hardware of the M2000 server and disk array is functional. ----End
13.2.17 Checking the SMC Collection Results

This section describes how to check the SMC collection results and to ensure that the M2000 server environment is normal.
Prerequisite
l l l
The SMC server software runs properly. The SMC client software runs properly. You have the password of user root to log in to the M2000 server.
Issue 03 (2010-08-31)
Procedure
Step 1 On the SMC client, log in to the server as user root. Step 2 Enter Sun Management Center and check the SMC collection results. For detailed operations, see the relevant manual of the SMC. You can obtain the relevant SMC manual at the Sun website. ----End
13.3 Weekly Maintenance Operations (HA)

This section describes the weekly maintenance operations that need to be performed on the M2000 HA system. 13.3.1 Checking the Configuration of Alarm Timing This section describes how to check whether the policy on automatic dumping alarm data from the alarm database is reasonable. 13.3.2 Checking the Configuration of Automatic Log Dump This section describes how to check whether the system of automatic dumping alarm data from the alarm database is satisfactory. 13.3.3 Checking the Synchronization Time of NE Log This section describes how to check whether the configuration of synchronization time of the NE log is correct. The purpose is to avoid the server overload owing to the conflict of time when you perform tasks on the server. 13.3.4 Checking the Configuration of the File Server This section describes how to check whether the configuration of the file server is appropriate. 13.3.5 Checking the Configuration of System Backup This section describes how to check whether the periodic backup of the M2000 server and NEs are started and whether the start time is correct. The purpose is to avoid the server overload owing to the conflict of time when you perform tasks on the server. This section also describes how to check whether backup files are generated in the disk. 13.3.6 Checking the Configuration of System Monitoring This section describes how to check the configuration of system monitoring. 13.3.7 Checking the Synchronization Time of NE Configuration This section describes how to check whether the time for synchronizing NE configuration data is appropriate. The purpose is to avoid the server overload. The server overload may occur when the synchronization together with other tasks on the server is performed at the same time. 13.3.8 Checking the Threshold of Network Management Capability This section describes how to check whether the M2000 management capability exceeds the threshold. Ensure that the number of equivalent NEs managed by the M2000 does not exceed the capability limit. 13.3.9 Checking the Status of the M2000 Routes This section describes how to check the configuration of the M2000 routes. 13.3.10 Backing Up the M2000 This section describes how to back up the M2000 . The M2000 backup refers to the backup of M2000 databases and system files. The M2000 databases consists of omcdb, omclogdb,
omcsmdb, omctmdb, fmdb, pmdb, swmdb, pmcomdb, sumdb, itfndb, farsdb and omceamdb. The M2000 system files refer to those files in the directories /export/home/omc/var and / export/home/sysm. 13.3.11 Checking the Time of the M2000 Server (HA) This section describes how to check the time of the M2000 server. 13.3.12 Checking the States of M2000 Disks This section describes how to check all the disks in the VxVM, the logical volumes of the local disk in the VxVM, and the logical volumes of the disk array in the VxVM.
13.3.1 Checking the Configuration of Alarm Timing

This section describes how to check whether the policy on automatic dumping alarm data from the alarm database is reasonable.
Prerequisite
l l
You have logged in to the M2000. You are authorized to check the configuration of M2000 integrated task management.
Procedure
Step 1 Choose Maintenance > Task Management. The Task Management window is displayed. Step 2 Under the Database Capacity Management node in the Task Type navigation tree in the left pane, select the Alarm Data node. You can also double-click the Alarm/Event Log Dump node to open the Attributes window. Step 3 Select the task in the right pane and click Attribute. Step 4 In the Attribute window, check the configuration of automatic alarm data dumping. Step 5 Ensure that the configuration of automatic alarm data dumping is proper. ----End
13.3.2 Checking the Configuration of Automatic Log Dump

This section describes how to check whether the system of automatic dumping alarm data from the alarm database is satisfactory.
Prerequisite
l l
You have logged in to the M2000 . You are authorized to check the configuration of M2000 integrated task management.
Procedure
Step 1 Choose Maintenance > Task Management. The Task Management window is displayed.
Step 2 Check the configuration of automatic log dump of NE operation logs. 1. 2. 3. 4. Under the Database Capacity Management node in the Task Type navigation tree in the left pane, select NE Operation Log. Choose the task in the right pane. Click Attribute. Check the configuration of auto NE operation log dump in the Attribute window. Ensure that the configuration is reasonable.
Step 3 Check the configuration of automatic log dump of NE security logs. 1. 2. 3. 4. Under the Database Capacity Management node in the Task Type navigation tree in the left pane, select NE Security Log. Choose the task in the right pane. Click Attribute. Check the configuration of auto NE security log dump in the Attribute window. Ensure that the configuration is reasonable.
Step 4 Check the configuration of automatic log dump of NE system logs. 1. 2. 3. 4. Under the Database Capacity Management node in the Task Type navigation tree in the left pane, select NE System Log. Choose the task in the right pane. Click Attribute. Check the configuration of auto NE system log dump in the Attribute window. Ensure that the configuration is reasonable.
Step 5 Check the configuration of automatic log dump of NM operation logs. 1. 2. 3. 4. Under the Database Capacity Management node in the Task Type navigation tree in the left pane, select NM Operation Log Dump. Choose the task in the right pane. Click Attribute. Check the configuration of auto NM operation log dump in the Attribute window. Ensure that the configuration is reasonable.
Step 6 Check the configuration of automatic log dump of NM system logs. 1. 2. 3. 4. Under the Database Capacity Management node in the Task Type navigation tree in the left pane, select NM System Log Dump. Choose the task in the right pane. Click Attribute. Check the configuration of auto NM system log dump in the Attribute window. Ensure that the configuration is reasonable.
Step 7 Check the configuration of automatic log dump of NM security logs. 1. 2. 3. 4. Under the Database Capacity Management node in the Task Type navigation tree in the left pane, select NM Security Log Dump. Choose the task in the right pane. Click Attribute. Check the configuration of auto NM security log dump in the Attribute window. Ensure that the configuration is reasonable.
----End
13-20
Issue 03 (2010-08-31)
13.3.3 Checking the Synchronization Time of NE Log

This section describes how to check whether the configuration of synchronization time of the NE log is correct. The purpose is to avoid the server overload owing to the conflict of time when you perform tasks on the server.
Prerequisite
l l
You have logged in to the M2000. You are authorized to check the configuration of the M2000 integrated task management.
Context
You need to run the operation only if the NE supporting this function exists.
Procedure
Step 1 Choose Maintenance > Task Management. The Task Management window is displayed. Step 2 Under the Synchronization node in the Task Type navigation tree in the left pane, select NE Log Synchronization. Step 3 Select the task in the right pane. Click Attribute. Step 4 View the configuration of synchronization time of NE log in the Attribute dialog box. Step 5 Ensure that the configuration is correct. You are advised to synchronize NE logs when the traffic is not heavy. Generally, this operation is performed at night when no other tasks are performed. ----End
13.3.4 Checking the Configuration of the File Server

This section describes how to check whether the configuration of the file server is appropriate.
Prerequisite
l l
You have logged in to the M2000. You are authorized to check the configuration of the M2000 file server.
Procedure
Step 1 Choose Software > File Server Setting. The File Server Setting window is displayed. Step 2 Select the NE type in the ROOT navigation tree in the left pane. Step 3 Check the name and IP address of the file server in the right pane. Step 4 Ensure that the configuration of the file server is appropriate. ----End
13.3.5 Checking the Configuration of System Backup

This section describes how to check whether the periodic backup of the M2000 server and NEs are started and whether the start time is correct. The purpose is to avoid the server overload owing to the conflict of time when you perform tasks on the server. This section also describes how to check whether backup files are generated in the disk.
Prerequisite
l l
You have logged in to the M2000. You are authorized to check the configuration of the M2000 integration task.
Procedure
Step 1 Choose Maintenance > Task Management. The Task Management window is displayed. Step 2 Check whether the periodic backup of the M2000 server is started and whether the start time is correct. 1. 2. 3. 4. 5. 1. 2. 3. 4. Under the Backup node in the Task Type navigation tree in the left pane, select the Server Backup node. View Last Run Time and State in the right pane. Ensure that the task is running in the execution time. Select the task in the right pane. Click Attribute. View the configuration of periodic backup time for the M2000 server in the Attribute dialog box. Ensure that the configuration is correct. Under the Backup node in the Task Type navigation tree in the left pane, select the NE Backup node. View Last Run Time and State in the right pane. Ensure that the task is running in the execution time. Select the task in the right pane. Click Attribute. View the configuration of periodic backup time for NEs in the Attribute dialog box. Ensure that the configuration is correct.
Step 3 Check whether the periodic backup of the NE is started and whether the start time is appropriate.
Step 4 Log in to the M2000 server as user omcuser through SSH mode. Check whether backup files exist in the backup directory of both the M2000 server and NEs. You can specify the backup directory for the M2000 server and NEs based on the attribute information. ----End
13.3.6 Checking the Configuration of System Monitoring

This section describes how to check the configuration of system monitoring.
Context
The recommended thresholds of the CPU usage, memory usage, and database usage are 80%.
Procedure
Step 1 Choose Monitor > System Monitor > Settings. The System Monitor Settings dialog box is displayed. Step 2 Click the Server Monitor tab to check whether the settings of the CPU usage and memory usage thresholds are appropriate. Step 3 Click the Hard Disk Monitor tab to check whether the settings of the disk usage thresholds are appropriate. Step 4 Click the Database Monitor tab to check whether the settings of the database usage thresholds are appropriate. Step 5 Click the Service Monitor tab to check whether the settings of the service status refresh interval thresholds are appropriate. ----End
Example
For details about the parameters for monitoring the server, see Table 13-10.
Issue 03 (2010-08-31)
13-23
l
13-24
Issue 03 (2010-08-31)
l
Table 13-11 describes the parameters for monitoring the disks of the server.
l
l l l l

l l l l
13-26
Issue 03 (2010-08-31)
l
Settings Value:
l
Table 13-12 describes the parameters for monitoring the database of the server. Table 13-12 Database Monitor Name Database Monitor Parameter Settings Database status refresh interval (300-3600 seconds) Description Description: Interval of database refreshing. Settings Value: Value range: 300-3600 Default value: 300
l

l l l l
13-28
Issue 03 (2010-08-31)
l
l

Table 13-13 describes the parameters for monitoring the server services. Table 13-13 Service Monitor Name Services Monitor Parameter Settings Service status refresh interval (60-3600 seconds) Description Description: Interval of service refreshing. Settings Value: Value range: 60-3600 Default value: 60
Issue 03 (2010-08-31)
13-29
l if a monitored

l You can double-
13.3.7 Checking the Synchronization Time of NE Configuration

This section describes how to check whether the time for synchronizing NE configuration data is appropriate. The purpose is to avoid the server overload. The server overload may occur when the synchronization together with other tasks on the server is performed at the same time.
Prerequisite
l l
You have logged in to the M2000. You are authorized to check the configuration of the M2000 integrated task management.
Context
You need to run the operation only if the NE supporting this function exists.
Procedure
Step 1 Choose Maintenance > Task Management. The Task Management window is displayed. Step 2 Under the Synchronization node in the Task Type navigation tree in the left pane, select the NE Configuration Data Synchronization node. Step 3 Select the task in the right pane. Click Attribute.
Step 4 View the setting of the time for synchronizing NE configuration data in the Attribute dialog box. Step 5 Ensure that the configuration is correct. ----End
13.3.8 Checking the Threshold of Network Management Capability

This section describes how to check whether the M2000 management capability exceeds the threshold. Ensure that the number of equivalent NEs managed by the M2000 does not exceed the capability limit.
Procedure
Step 1 Check whether the M2000 management capability exceeds the threshold. Ensure that the number of equivalent NEs managed by the M2000 is not beyond the capacity. For details on how to calculate equivalent NEs and for the description of the M2000 management capability, refer to the M2000 Product Description. ----End
13.3.9 Checking the Status of the M2000 Routes

This section describes how to check the configuration of the M2000 routes.
Prerequisite
Procedure
Step 1 Check the configuration of the current route. # netstat -rnv ----End
13.3.10 Backing Up the M2000

This section describes how to back up the M2000 . The M2000 backup refers to the backup of M2000 databases and system files. The M2000 databases consists of omcdb, omclogdb, omcsmdb, omctmdb, fmdb, pmdb, swmdb, pmcomdb, sumdb, itfndb, farsdb and omceamdb. The M2000 system files refer to those files in the directories /export/home/omc/var and / export/home/sysm.
Prerequisite
l l
You have logged in to the M2000 . You are authorized to back up the M2000 system.
Issue 03 (2010-08-31)
13-31
Context
NOTE
The time required for backing up data is related to the actual environment. Generally, it takes about five hours. Do not suspend a periodic backup task. The reasons are as follows:
l l
Procedure
Step 1 On the main window, choose Maintenance > Task Management. The Task Management dialog box is displayed. Step 2 Choose Task Type > Backup > Server Backup from the navigation tree, and then double-click the Server Backup node. The Attribute dialog box is displayed, as shown in Figure 13-1. Figure 13-1 Periodic backup
13.3.11 Checking the Time of the M2000 Server (HA)

This section describes how to check the time of the M2000 server.
Prerequisite
Procedure
Step 1 Check the time of the M2000 server. # date The server time is displayed, for example:
Tue Mar 29 00:35:24 MEST 2005
Step 2 If the M2000 server is configured with the NTP service, run the command ps -ef | grep ntp | grep -v grep to check whether the NTP service is started. Ensure that the NTP service is started
and check the service status according to 4.5.7 Checking the Running Status of the NTP Service on the M2000 Server (HA). Step 3 Handle exceptional situations.
l
Change the server time if it is incorrectly set or it is not synchronized with the external clock source through NTP. For details on how to handle the problem, refer to 4 Setting the M2000 Time (HA). If the M2000 is configured with the NTP service and the NTP service is not running properly, handle the problem according to 4.5 Configuring the NTP Service of the M2000 (HA).
Step 4 Check whether the M2000 works properly. Ensure that the server time is correct. ----End
13.3.12 Checking the States of M2000 Disks

This section describes how to check all the disks in the VxVM, the logical volumes of the local disk in the VxVM, and the logical volumes of the disk array in the VxVM.
Prerequisite
Log in to the M2000 server as user root through SSH mode. In the HA system, log in to the active node.
Context
The following operation applies only for the M2000 server configured with disk array.
Procedure
Step 1 Check all the disks in the VxVM. # vxdisk -g name of the disk group list Assume that the name of the disk array is ossdg. Run the following command: # vxdisk -g ossdg list The following information is an example of the command result:
DEVICE c4t2d1s2 TYPE auto:cdsdisk DISK ossdisk-1 GROUP ossdg STATUS online
Generally, all the values in the STATUS column in the command result are online. Step 2 Check the logical volumes of the disk array in the VxVM: # vxprint -g ossdg
NOTE
In the command result, all the values of pl, sd, and v in the KSTATE column are ENABLED and all the values of pl and v in the STATE column are ACTIVE.
Step 3 Ensure that the M2000 disks are functioning properly. # df -k

Ensure that the usage ratio of each partition is smaller than 90%. If the usage ratio of a partition is greater than 90%, you must clean the disk immediately. For details on how to clean a disk, refer to 11.2.3 Clearing the Disk Space of the M2000 Server. ----End
13.4 Monthly Maintenance Operations (HA)

This section describes the monthly maintenance operations that need to be performed on the M2000 HA system. 13.4.1 Checking the Power Supply of the M2000 Server This section describes how to check the power supply of the M2000 server. 13.4.2 Checking the Peripherals of the M2000 Server This section describes how to check the peripherals of the M2000 server, such as the CD-ROM drive and the tape drive. 13.4.3 Checking the Timeout for Stopping the M2000 Application Resources This section describes how to check the preset timeout for stopping the M2000 application resources to ensure that the value is correct. 13.4.4 Checking the Trust Between Two Servers in an HA System This section describes how to check the trust between two servers in an HA system to ensure that the trust is normal. 13.4.5 Checking the Version of the Sun Cluster Software This section describes how to check the version of the Sun Cluster software to ensure that the version number is the same on both nodes. 13.4.6 Checking the Global Devices of an HA System This section describes how to check the global devices of an HA system to ensure that both the active and standby nodes can identify the shared disk. 13.4.7 Checking the Logical Host of an HA System This section describes the logical host of an HA system to ensure that the active/standby relation is normal. 13.4.8 Checking the Right and Owner of the /opt/SUNWscsyb/bin/sybase_stop_servers File This section describes how to ensure that the right and owner of the /opt/SUNWscsyb/bin/ sybase_stop_servers file are set correctly. 13.4.9 Checking the Front Panel of a Disk Array This section describes how to check the front panel of each disk array to determine whether a disk array is damaged. 13.4.10 Querying the M2000 License This section describes how to query the license file on the M2000 server through the M2000 client.
13.4.1 Checking the Power Supply of the M2000 Server

This section describes how to check the power supply of the M2000 server.
Prerequisite
The M2000 server is switched on.
Procedure
Step 1 Check power supply indicators. All power indicators are green. All fault indicators are dim. Step 2 Check the power supply indicators of the disk array and the storage device. Green indicators are on or blinking. Step 3 Check the latest power supply fault records in system logs of the Solaris. The system logs do not contain any fault related records. Step 4 Check the external power supply. The external power supply is functional. Step 5 Handle exceptional situations. The Solaris system log records the faults of the power supply housed in the Sun cabinet. For the external power supply, that is, the power supply outside the Sun cabinet, check the power supply and circuits according to the delivery-attached manual of the server. If the fault is complex, contact the engineers at Sun Microsystems. Step 6 Ensure that the power of the M2000 works normally. All power indicators must be green and all fault indicators must be dim. ----End
13.4.2 Checking the Peripherals of the M2000 Server

This section describes how to check the peripherals of the M2000 server, such as the CD-ROM drive and the tape drive.
Prerequisite
The M2000 system is switched on.
Procedure
Step 1 Check the CD-ROM drive. The CD-ROM drive works properly. Step 2 Check the tape drive. The tape drive works properly. Step 3 If the server uses the StorEdge D240, check whether the StorEdge D240 is functional.
l
The green light of the power indicator on the right of the front panel is on, and the indicator of system faults is off. In the middle of the front panel, there is one hard disk indicator available in both upper line and lower line. The green light of the hard disk indicators are on or blinking. For the two power modules in the rear panel, the green indicator of DC power output is on, the fault indicator is off, the blue service indicator is on, and the green indicator of AC power input is on.
13-36
Step 4 Handle exceptional situations. For details on how to handle the faults of the CD-ROM drive and the tape drive, refer to the Solaris Administrator Guide. Step 5 Check whether the peripherals of the server works normally. For details on how to handle the faults of the CD-ROM and the tape drive, refer to the Solaris Administrator Guide. ----End
13.4.3 Checking the Timeout for Stopping the M2000 Application Resources
This section describes how to check the preset timeout for stopping the M2000 application resources to ensure that the value is correct.
Prerequisite
Log in to the active node as user root through SSH mode.
Context
When the preset timeout for stopping the M2000 application resources is less than 1,800s, the system uses the kill_daem command to forcibly stop the M2000 services if the services are not stopped within 30 min. As a result, the M2000 services are disrupted abnormally.
Procedure
Step 1 Run the following command on the active node to check the timeout for stopping the M2000 application resources: # scha_resource_get -G oss_rs -R ossapp_rs -O STOP_TIMEOUT The system displays the following information: 1800 The displayed value is the timeout for stopping the M2000 application resources.
l l
If the displayed value is 1800, you need not perform the following operations. If the displayed value is not 1800, proceed with Step 2 through Step 3.
Step 2 Run the following command on the active node to change the timeout for stopping the M2000 application resources: # scrgadm -c -j ossapp_rs -y STOP_TIMEOUT=1800 Step 3 Run the following command on the active node to check whether the timeout for stopping the M2000 application resources is correct: # scha_resource_get -G oss_rs -R ossapp_rs -O STOP_TIMEOUT ----End
13.4.4 Checking the Trust Between Two Servers in an HA System

This section describes how to check the trust between two servers in an HA system to ensure that the trust is normal.
Prerequisite
Context
Trust is the mutually trustful relation configured for a specified user between two servers. The specified user need not type a password when logging in to the mutually trustful server in Rlogin mode, and owns all the rights on another server. Trust is required in operations related to version upgrade and data collection.
Procedure
Step 1 Run the following command on the active and standby nodes to obtain the host name of the server: # hostname Step 2 Run the following command on the active node to log in to the standby node: # rsh host name of the standby node
l
If no password is required for login, you can infer that the trust between the active node and the standby node is normal. In this case, run the exit command to return to the command line window of the active node, and then proceed with Step 3. If the system prompts you to type a password, you can infer that the trust between the active node and the standby node is abnormal. In this case, you need to type a correct password for login before running the exit command to return to the command line window of the active node. Then, proceed with Step 4.
Step 3 Run the following command on the standby node to log in to the active node: # rsh host name of the active node
l
If no password is required for login, you can infer that the trust between the active node and the standby node is normal, that is, the trust between the two servers in the HA system is normal. In this case, run the exit command to return to the command line window of the standby node. You need not perform the following operations. If the system prompts you to type a password, you can infer that the trust between the active node and the standby node is abnormal. In this case, you need to type a correct password for login before running the exit command to return to the command line window of the standby node. Then, proceed with Step 4.
Step 4 Run the following command on the active and standby nodes to modify the /.rhosts file, that is, add the host names of the two nodes to this file: # TERM=vt100; export=TERM # vi /.rhosts After the file is modified, press Esc and then run the :wq! command to save the modification and exit.

NOTE
If the host names of the two nodes are available in the file, you need not modify the file. Press Esc and run the :q command to exit.
Step 5 Repeat Step 2 and Step 3 to check the trust between the two servers in the HA system. If the trust is abnormal, contact Huawei technical support engineers for assistance. ----End
13.4.5 Checking the Version of the Sun Cluster Software

This section describes how to check the version of the Sun Cluster software to ensure that the version number is the same on both nodes.
Prerequisite
l l
Log in to the active and standby nodes as user root through SSH mode. The Sun Cluster software is installed.
Procedure
Step 1 Run the following command on both nodes to check the version of the Sun Cluster software: # scinstall -pvv The system displays the following information: Sun Cluster 3.2 for Solaris 10 sparc According to the preceding information, you can infer that the version of the Sun Cluster software is 3.2. If the version number of the Sun Cluster software is different on the two nodes, contact Huawei technical support engineers for assistance. ----End
13.4.6 Checking the Global Devices of an HA System

This section describes how to check the global devices of an HA system to ensure that both the active and standby nodes can identify the shared disk.
Prerequisite
Log in to the active node as user root through SSH mode.
Procedure
Step 1 Run the following command to display the information about the current global devices: # scdidadm -L The system displays the following information:
1 2 3 osssvr-1:/dev/rdsk/c0t0d0 osssvr-1:/dev/rdsk/c1t0d0 osssvr-1:/dev/rdsk/c1t1d0 /dev/did/rdsk/d1 /dev/did/rdsk/d2 /dev/did/rdsk/d3
Issue 03 (2010-08-31)
13-39

4 d4 4 d4 5 d5 5 d5 6 d6 6 d6 7 d7 7 d7 8 9 10
osssvr-1:/dev/rdsk/c4t600A0B800048F980000018D749D4539Ed0 /dev/did/rdsk/ osssvr-2:/dev/rdsk/c4t600A0B800048F980000018D749D4539Ed0 /dev/did/rdsk/ osssvr-1:/dev/rdsk/c4t600A0B800048F980000018D449D45312d0 /dev/did/rdsk/ osssvr-2:/dev/rdsk/c4t600A0B800048F980000018D449D45312d0 /dev/did/rdsk/ osssvr-1:/dev/rdsk/c4t600A0B800048F82C000019E74AAD5AAEd0 /dev/did/rdsk/ osssvr-2:/dev/rdsk/c4t600A0B800048F82C000019E74AAD5AAEd0 /dev/did/rdsk/ osssvr-1:/dev/rdsk/c4t600A0B800048F82C000019DA4AAD597Ad0 /dev/did/rdsk/ osssvr-2:/dev/rdsk/c4t600A0B800048F82C000019DA4AAD597Ad0 /dev/did/rdsk/ osssvr-2:/dev/rdsk/c0t0d0 osssvr-2:/dev/rdsk/c1t0d0 osssvr-2:/dev/rdsk/c1t1d0 /dev/did/rdsk/d8 /dev/did/rdsk/d9 /dev/did/rdsk/d10
The information similar to /dev/rdsk/ c4t600A0B800048F980000018D749D4539Ed0 /dev/did/rdsk/d4 is the information about the logical partitions of the disk array. In the HA system, the disk array is shared by both nodes. Therefore, each logical partition belongs to both nodes, for example:
osssvr-1:/dev/rdsk/c4t600A0B800048F980000018D749D4539Ed0 /dev/did/rdsk/d4 osssvr-2:/dev/rdsk/c4t600A0B800048F980000018D749D4539Ed0 /dev/did/rdsk/d4
If the logical partitions of the disk array in the system output belongs to only one node, you need to contact Huawei technical support engineers for assistance. ----End
13.4.7 Checking the Logical Host of an HA System

This section describes the logical host of an HA system to ensure that the active/standby relation is normal.
Prerequisite
Procedure
Step 1 Run the following command on either node to determine the active node and the standby node: # scstat -D In the system output, the node corresponding to the Primary column is the active node and the node corresponding to the Secondary column is the standby node. Normally, node 1 is the active node and node 2 is the standby node. If the active/standby relation is abnormal, contact Huawei technical support engineers for assistance. ----End
13.4.8 Checking the Right and Owner of the /opt/SUNWscsyb/bin/ sybase_stop_servers File
This section describes how to ensure that the right and owner of the /opt/SUNWscsyb/bin/ sybase_stop_servers file are set correctly.
Prerequisite
Procedure
Step 1 Run the following command on the active and standby nodes to check whether the right and owner of the sybase_stop_servers file is correct: # ls -l /opt/SUNWscsyb/bin/sybase_stop_servers
-r-x-----1 dbuser sybase_stop_servers staff 2180 Oct 15 10:30 /opt/SUNWscsyb/bin/
The owner and right of the sybase_stop_servers file are dbuser and r-x------ (500), respectively. If the right and owner of the file are correct, you need not perform the following operations. Otherwise, proceed with Step 2 and Step 3. Step 2 Run the following commands on the active and standby nodes to change the right and owner of the sybase_stop_servers file: # chmod 500 /opt/SUNWscsyb/bin/sybase_stop_servers # chown dbuser:staff /opt/SUNWscsyb/bin/sybase_stop_servers Step 3 Repeat Step 1 to check whether the right and owner of the sybase_stop_servers file are set correctly. ----End
13.4.9 Checking the Front Panel of a Disk Array

This section describes how to check the front panel of each disk array to determine whether a disk array is damaged.
Procedure
Step 1 Check whether the LED indicator of the front panel of a disk array is yellow. If the LED indicator is yellow, you can infer that a configuration or hardware fault occurs on the power supply, controller, or disk array. In this case, contact Huawei technical support engineers for assistance. ----End
13.4.10 Querying the M2000 License

This section describes how to query the license file on the M2000 server through the M2000 client.
Procedure
Step 1 Choose License > OMC License Management > License Information. Step 2 In the License Information dialog box, query the license information about resources and functions on the Resource control item and Function control item tabs. ----End
14 M2000 Emergency Maintenance (HA)
14
M2000 Emergency Maintenance (HA)
About This Chapter

This chapter describes the emergency maintenance procedures for serious faults in the server and clients of the M2000 HA system. These procedures include the emergency maintenance for the server in the M2000 HA system and the M2000 clients, and the procedure for powering off the M2000 server in exceptional situations. 14.1 Guide to Emergency Maintenance of the M2000 Server This provides guidance for emergency maintenance when serious faults occur in the M2000 system. 14.2 Guide to Emergency Maintenance of the M2000 Client This section provides guidance for emergency maintenance of the M2000 client. 14.3 Guide to Emergency Maintenance of the M2000 Server in Case of Power Failure (HA) This provides guidance for emergency maintenance of the M2000 client.
Issue 03 (2010-08-31)
14-1
14.1 Guide to Emergency Maintenance of the M2000 Server

This provides guidance for emergency maintenance when serious faults occur in the M2000 system. The M2000 server emergency maintenance is based on the backup. When serious faults occur in the server, restore the server in the following ways:
l
Through the BRT tool You can use the BRT tool to back up operating system data on a tape. To restore system data, you need to boot the server by using the installation CD-ROM of the operating system, restore the BRT tool from the tape, and then restore the system data by using the script in the BRT tool.
Using the backup server Restore the operating system from the backup server if a full system backup is made through the Veritas software.
By reinstalling the operating system

NOTE
If the system is not backed up, all user data is lost if the system crashes due to fatal errors. In this case, reinstall the operating system.
14.2 Guide to Emergency Maintenance of the M2000 Client

This section provides guidance for emergency maintenance of the M2000 client. If the M2000 client breaks down or a fault occurs in the client, you can restore the client in the following ways:
l l
Reinstall the operating system on the M2000 client. Reinstall the M2000 system.
14.3 Guide to Emergency Maintenance of the M2000 Server in Case of Power Failure (HA)
This provides guidance for emergency maintenance of the M2000 client. 14.3.1 Troubleshooting: Failure to Start the Solaris Due to Loss of System Files This section describes how to handle the failure to start the Solaris operating system owing to the loss of system files. 14.3.2 Troubleshooting: System Switched into the Maintenance Mode and Prompting You to Run fsck Manually This section describes how to manually run the fsck command in maintenance mode. 14.3.3 Troubleshooting: Loss of Database Device Files After the Restoration of the File System (HA) This section describes how to handle the loss of database device files after the restoration of the file system.
14.3.4 Troubleshooting: Failure to Restore the Database Though the File System Is Intact (HA) This section describes how to handle the failure to restore the database though the file system is intact.
14.3.1 Troubleshooting: Failure to Start the Solaris Due to Loss of System Files
This section describes how to handle the failure to start the Solaris operating system owing to the loss of system files.
Symptom
The server cannot be started. The system displays the message Cannot open `/etc/ path_to_inst` . After resetting the server, you are not allowed to log in to the server through the SSH or Telnet and not allowed to ping the server. Use the serial port or the SC/RSC/XSCF port to view the following information:
Cannot open `/etc/path_to_inst` Program terminated
The system stops functioning and is switched to the ok status.
Fault Handling
Unexpected power-off of the server damages the Solaris operating system. As a result, the system file path_to_inst is lost. The Solaris operating system, therefore, fails to start. 1. 2. Press Stop+a or Ctrl+Break to exit the startup and switch to the ok status. Only the keyboard delivered with the server has the stop key. Insert the boot disk of the Solaris operating system, that is, the first of the two installation disks, into the CD-ROM. Run the following command in the ok status: ok boot cdrom -s 3. Run the following commands to search for the name of the basic device corresponding to the system root folder: # cd /dev/dsk # ls 4. Mount this basic device to the /mnt mount point. Assume that the name of the basic device corresponding to the root folder is c0t0d0s0. Run the mount /dev/dsk/c0t0d0s0 /mnt command to switch to /mnt to restore the Solaris operating system.
CAUTION
If the /etc/path_to_inst file is lost, restore it using the path_to_inst-INSTALL template stored in the /etc folder. Run the following commands: # cd /mnt/etc # cp path_to_inst-INSTALL path_to_inst
Issue 03 (2010-08-31)
14-3
5.
Run the following commands to reset the Solaris operating system: # sync; sync; sync; sync; sync; sync # /usr/sbin/shutdown -g0 -y -i6 After the system starts, run the fsck -y command to restore the system file. Start the Sybase and M2000 application manually.
14.3.2 Troubleshooting: System Switched into the Maintenance Mode and Prompting You to Run fsck Manually
This section describes how to manually run the fsck command in maintenance mode.
Symptom
The server cannot be started and can be switched only to the maintenance mode. The system displays the message Run fsck manually (fsck -F ufs /dev/rdsk/ c*t*d*s*). After resetting the server, you are not allowed to log in to the server through the SSH or Telnet. Use a serial port or the SC/RSC/XSCF port to view the following information:
WARNING - Unable to repair the / filesystem. Run fsck manually (fsck -F ufs /dev/rdsk/c*t*d*s*). Exit the shell when done to continue the boot process. Type control-d to proceed with normal startup, (or give root password for system maintenance):
NOTE
The warning shows Unable to repair the / filesystem, where filesystem may refer to other partitions.
Fault Handling
The exceptional server power-off damages the Solaris. You must restore the Solaris manually. 1. 2. 3. Log in to the server as user root. Modify the file system. # fsck -y Check the restored information. Ensure that the file systems of all partitions are correct, that the file system of the damaged partition is restored, and that the database device files are complete. After the file system is restored, switch to the /export/home/sybdev folder and check whether the database device files are complete. The database device files are as follows:
master.dat sysproce.dat tmp_dev.dat
4.
CAUTION
If the M2000 HA system uses Netra 240 servers, the database device files exist in the / export/home/sybase/data directory. 5. Ensure that the SYB.krg file is deleted. When the server powers off abnormally, the Sybase also exits abnormally and the /opt/sybase/ASE-15_0/SYB.krg file is not deleted. The file
14-4
disables the startup of the Sybase. Therefore, delete the file if it still exists after you reset the Solaris. If any database device files are lost, refer to 14.3.3 Troubleshooting: Loss of Database Device Files After the Restoration of the File System (HA).
14.3.3 Troubleshooting: Loss of Database Device Files After the Restoration of the File System (HA)
This section describes how to handle the loss of database device files after the restoration of the file system.
Symptom
If a device file related to the system database, such as master.dat or sysprocs.dat, is lost, the database fails to start. If a device file related to some application database is lost, the corresponding application database and the services related to this database fail to start.
Fault Handling
The abnormal power-off leads to loss of the database device file in the file system. 1. Delete the following three files, and then reinstall the Sybase database.
l l l
/opt/sybase/interfaces /export/home/sybdev/master.dat /export/home/sybdev/sysprocs.dat
CAUTION
When the Netra 240 server is used, the master.dat and sysprocs.dat files exist in the / export/home/sybase/data directory. 2. When installing the database, select reinstall to reestablish the application databases of M2000. For details on the installation of the Sybase and the M2000 , refer to the software installation manual related to each server type. Perform the full backup and incremental backup to restore the data in the database and M2000 configuration files.
3.
14.3.4 Troubleshooting: Failure to Restore the Database Though the File System Is Intact (HA)
This section describes how to handle the failure to restore the database though the file system is intact.
Symptom
After the server is shut down exceptionally, the operating system can be restarted normally. The file system can work normally, and the database service can be started. Part of databases,
however, are in the suspect status and cannot be started. After checking the application database, find that the application database is in the offline status. To check whether a database is in the offline status, run the following commands: -bash-3.00$ isql -Sdatabase server name -Usa -Ppassword of user sa 1> sp_helpdb 2> go The database log file /opt/sybase/ASE-15_0/install/database server name.log records the following error information:
00:00000:00001:2005/07/24 18:56:29.08 server Error: 926, Severity: 14, State: 1 00:00000:00001:2005/07/24 18:56:29.08 server Database 'swmdb' cannot be opened. An earlier attempt at recovery marked it 'suspect'. Check the SQL Server errorlog for information as to the cause.
NOTE
Fault Handling
The database is processing transactions when the server is switched off abnormally. The abnormal exit leads to an exception in the database. To handle the fault, perform the following steps: 1. Log in to the M2000 installation directory as user root through SSH mode and run the environment variable script. The default M2000 installation directory is /opt/OMC. # cd M2000 installation path # . ./svc_profile.sh 2. Switch to user dbuser and log in to the database as user sa. Then, run the following commands: # su - dbuser -bash-3.00$ isql -Sdatabase server name -Usa -Ppassword of user sa 1> sp_configure "allow updates", 1 2> go 1> update master..sysdatabases set status =-32768 2> where name="database_name" 3> go 1> exit -bash-3.00$ exit For details on how to stop the database service, see 16.2.3 How to Stop the Sybase (HA, Sun).
CAUTION
The parameter database_name indicates the name of the faulty database. 3. Log in as user root and check whether all the values in /opt/sybase/ASE-15_0/database server name.cfg are changed to the default values. If all the values are changed to the default values, restore the database by using the history file. (1) Run the following commands to query the last history file: # cd /opt/sybase/ASE-15_0 # ls -l database server name.* The command result is similar with the following information:
-rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rw-r--r--rwxrwxrwx -rw------1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser dbuser staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff staff 9620 9690 9696 9690 9696 9690 9696 9690 9696 9690 9696 9690 9696 9690 9696 9690 9696 9690 9696 9695 9694 9693 9801 9797 9794 9792 9790 9785 9780 9779 9778 9772 9770 9764 9758 9756 9753 9752 9753 9752 59 Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jun Jul Aug Jul Aug 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 24 9 6 9 6 16:26 16:26 16:26 16:26 16:27 16:27 16:27 16:27 16:27 16:27 16:27 16:27 16:27 16:27 16:27 16:27 16:27 16:27 16:27 16:34 16:34 16:34 16:34 16:34 16:35 16:35 16:35 16:35 16:35 16:35 16:35 16:35 16:35 16:35 16:35 16:35 16:35 09:51 11:25 09:51 11:25 SYB.001 SYB.002 SYB.003 SYB.004 SYB.005 SYB.006 SYB.007 SYB.008 SYB.009 SYB.010 SYB.011 SYB.012 SYB.013 SYB.014 SYB.015 SYB.016 SYB.017 SYB.018 SYB.019 SYB.020 SYB.021 SYB.022 SYB.023 SYB.024 SYB.025 SYB.026 SYB.027 SYB.028 SYB.029 SYB.030 SYB.031 SYB.032 SYB.033 SYB.034 SYB.035 SYB.036 SYB.037 SYB.038 SYB.bak SYB.cfg SYB.krg
As indicated in the command result, SYB.038 is the last history file. (2) Run the following command to use the last history file to restore /opt/sybase/ ASE-15_0/Database server name.cfg. This takes SYB and SYB.038, which are the database server name and the last history file respectively, as an example. # cp SYB.038 SYB.cfg # chown dbuser:staff SYB.cfg
4.
Start the Sybase. For details about how to start the Sybase, see 16.2.2 How to Start the Sybase (HA, Sun).
5.
Run the environment variable script as user root. # cd M2000 installation path # . ./svc_profile.sh
CAUTION
/opt/OMC is the default installation path of the M2000 server software. Replace the M2000 installation directory with the actual installation directory. 6. Switch to user dbuser and log in as user sa. Then, run the following commands: # su - dbuser -bash-3.00$ isql -Sdatabase server name -Usa -Ppassword of user sa 1> update master..sysdatabases set status =0 2> where name="database_name" 3> go 1>exit 7. Restart the Sybase. -bash-3.00$ exit For details on how to stop the database service, see 16.2.3 How to Stop the Sybase (HA, Sun). For details about how to start the Sybase, see 16.2.2 How to Start the Sybase (HA, Sun).
14-8
Issue 03 (2010-08-31)
15 Troubleshooting the M2000
15
About This Chapter
Troubleshooting the M2000
This chapter describes the procedures for troubleshooting the M2000. 15.1 Procedure for Troubleshooting the M2000 This section describes the procedure for troubleshooting the M2000. The procedure usually consists of three phases: collecting data, locating faults, and handling faults. 15.2 Collecting M2000 Site and Software Information This section describes how to collect the M2000 site and software information. 15.3 Collecting Fault Data Using the Log Information Collector This section describes how to collect fault data by using the M2000 log collector. You can also collect the information for locating faults by using the Trace Collection function of the OSMU system. For details, see the operation guide of the OSMU system.
Issue 03 (2010-08-31)
15-1
15.1 Procedure for Troubleshooting the M2000

This section describes the procedure for troubleshooting the M2000. The procedure usually consists of three phases: collecting data, locating faults, and handling faults.
Collecting Data
When a fault occurs, collect the following data:
l l l l l l l l l
Time when the fault has occurred Place where the fault has occurred Measures taken and the results Version information IP addresses Alarm information Logs Internal fault locating information Database deadlock information
NOTE
l l
Logs are categorized into user logs, system logs, and trace files. For details on viewing database deadlock information, refer to 16.2.6 How to View Database Deadlock Information.
Locating Faults
This section describes the procedure for locating faults. The collection and analysis of faults help you know the causes of the faults. The M2000 system faults are categorized into hardware faults and software faults.
l
Hardware faults Hardware faults are the faults that occur in the M2000 server, client, or other network devices. The appearance of the hardware and indicators indicate the hardware faults clearly.
Software faults Software faults are the faults that occur in the M2000 software, Solaris, and Sybase.
Handling Faults
This section describes how to handle faults based on different fault causes:
l
Hardware faults Refer to the manuals delivered with the associated hardware. Software faults For details on alarms, refer to the Help of the M2000 Mobile Element Management System. For details on faults of software installation, refer to the associated server type in the software installation manual related to each server type. For details on the client faults, refer to the M2000 Online Help.
15-2
Issue 03 (2010-08-31)
For details on the server faults, refer to the 16.3 About Server Software (HA, Sun).
l
Faults of the Solaris operating system Refer to the Solaris System Administrator Guide. You can download the Solaris System Administrator Guide at the website of the Sun corporation.
Sybase faults Refer to the Sybase System Administrator Guide. The Sybase System Administrator Guide can be obtained from the CD delivered with the server.
Uncleared faults For the uncleared faults, collect all the information related to the faults by referring to Collecting Data and contact Huawei technical support engineers for assistance.
15.2 Collecting M2000 Site and Software Information

This section describes how to collect the M2000 site and software information. 15.2.1 Collecting the M2000 Site Information This section describes how to collect the M2000 site information. 15.2.2 Collecting the Time of M2000 Fault Occurrence This section describes how to find out the time when M2000 faults occur. 15.2.3 Collecting the IP Address of the M2000 Server This section describes how to obtain the IP address of the M2000 server. 15.2.4 Collecting the Solaris Version This section describes how to obtain the version information about the Solaris. 15.2.5 Collecting Sybase Version Information This section describes how to collect the version information about the Sybase. 15.2.6 Obtaining the Version Information About the M2000 This section describes how to obtain the version information about the M2000.
15.2.1 Collecting the M2000 Site Information

This section describes how to collect the M2000 site information.
Procedure
Step 1 Collect the M2000 site information. Collect the following site information:
l l l l
Site name Customer contact details Hardware model Date and time when a fault occurs
Issue 03 (2010-08-31)

l
Fault description
----End
15.2.2 Collecting the Time of M2000 Fault Occurrence

This section describes how to find out the time when M2000 faults occur.
Procedure
Step 1 Log in to the server as user omcuser through SSH mode.
NOTE
If you fail to log in as user omcuser, log in as user root.
Step 2 Run the date command to check the time. ----End
Example
-bash-3.00$ date Thu Jul 28 09:56:39 EDT 2005
15.2.3 Collecting the IP Address of the M2000 Server

This section describes how to obtain the IP address of the M2000 server.
Procedure
NOTE
Step 2 Run the ifconfig -a command to obtain the IP address, subnet mask, and MAC address of the M2000 server. ----End
Example
-bash-3.00$ ifconfig -a
lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 10.161.94.254 netmask ffffff00 broadcast 10.161.94.255 ether 0:3:ba:12:bb:93
15.2.4 Collecting the Solaris Version

This section describes how to obtain the version information about the Solaris.
Procedure
NOTE
Step 2 Run the uname -aX command to find out the version information about the Solaris operating system. ----End
Example
-bash-3.00$ uname -aX A message similar to the following message is displayed:
SunOS BackupServer 5.10 Generic_138888-07 sun4u sparc SUNW,Netra-240System = SunO S Node = BackupServer Release = 5.10 KernelID = Generic_138888-07 Machine = sun4u BusType = <unknown> Serial = <unknown> Users = <unknown> OEM# = 0 Origin# = 1 NumCPU = 2
In the system output, Release specifies the version of the operating system and its value is 5.10; KernelID specifies version ID of the kernel and its value is Generic_118833-36, Generic_127111-09, Generic_138888-07 , Generic_141414-07 or a value indicating a later version.
15.2.5 Collecting Sybase Version Information

This section describes how to collect the version information about the Sybase.
Procedure
Step 1 Run the following commands: -bash-3.00$ isql -Sdatabase server name -Usa -Ppassword of user sa 1>select @@version 2>go
NOTE
----End
Example
-bash-3.00$ isql -Sdatabase server name -Usa -Ppassword of user sa 1>select @@version 2>go The system output is similar to the following information:
Adaptive Server Enterprise/15.0.2/EBF 15162 ESD#1 ONE-OFF/P/Sun_svr4/OS 5.8/ ase1502/2493/64-bit/FBO/Mon Oct 15 16:15:21 2007
In the system output, 15.0.2 is the current version number of the Sybase and 15162 is the version number of the patch that is installed. When the version number of the Sybase is 15.0.2, the version number of the patch must be 15162 or 15679. When the version number of the Sybase is 15.0.3, the version number of the patch must be 16548.
15.2.6 Obtaining the Version Information About the M2000

This section describes how to obtain the version information about the M2000.
Procedure
NOTE
Step 2 Run the displayVersion command to obtain the version information about the M2000. ----End
Example
Change to /opt/OMC, which is the default installation path of the M2000 server software. Run the following commands: -bash-3.00$ cd /opt/OMC -bash-3.00$ . ./svc_profile.sh -bash-3.00$ displayVersion
------------------------OMC Version-------------------------Product Name: iManagerM2000 Version: iManagerM2000V200R009ENGC00SPC805 Release Date: 06/09/09 ...
15-6
Issue 03 (2010-08-31)
15.3 Collecting Fault Data Using the Log Information Collector

This section describes how to collect fault data by using the M2000 log collector. You can also collect the information for locating faults by using the Trace Collection function of the OSMU system. For details, see the operation guide of the OSMU system.
Context
l
The start_collector process and the start_collector_agent process provide the service of the log collector. The start_collector process runs on the active node. The start_collector_agent process runs on the active node or the standby node. The service of the log collector is started upon the startup of the operating system. You can manually stop or start the service after the service is started. To start the service, run the /opt/OMC/bin/start_collector command and the /opt/OMC/ bin/start_collector_agent command. To stop the service, run the /opt/OMC/bin/stop_collector command and the /opt/OMC/ bin/stop_collector_agent command.
Procedure
Step 1 On the client, choose Start > Program > iManager M2000 Client > M2000 Log Information Collector . The Log Information Collector dialog box is displayed, as shown in Figure 15-1.
Issue 03 (2010-08-31)
15-7
Figure 15-1 Log Information Collector dialog box
NOTE
The shortcut menu M2000 Log Information Collector can be displayed when you choose Start > Program if you configure the shortcut menu during the installation of client. The default setting is iManager M2000 Client.
Step 2 In the Server Information area, enter the following information:

l l
Server Address: IP address of the active server. Port: FTP server port number. The default port number is 10119. If you change this number, you must also change the server settings. To change the server settings, log in to the server as user root. Run the stop_collector -port old port number command to shut down the original port. Then, run the start_collector -port new port number command. FTP User Name: ftpuser. Password: password of the Solaris user, such as ftpuser.
l l
Step 3 In Items Selection, select time and the information to be collected.

l l l l
Trace files in Local Host: collects the trace files of the local client. Trace files in server: collects the trace files of the login server. Core files in server: collects the core files of the login server. LMT trace file in server: collects the trace files of the LMT.
15-8

l
Standby Collection: collects the logs of the active node and the standby node at the same time. In the M2000 single-server system, do not select Standby Collection.
NOTE
Run the M2000 log information collector to collect fault information. Ensure that the start_collector process is running on the active node and the start_collector_agent process is running on the node where fault data collection is required. For example, if you select Standby Collection, the system collects the log information about the active and standby nodes. Therefore, you must ensure that the start_collector process is running on the active node and that the start_collector_agent process is running on the active node and the standby node. To check whether the log information collector is running, you can run the ps -ef | grep start_collector | grep -v grep command. Check whether the start_collector process and the start_collector_agent process are running on the corresponding nodes. If the processes are not started, run the /opt/OMC/bin/start_collector command to start the start_collector process and run the /opt/ OMC/bin/start_collector_agent command to start the start_collector_agent process.
Step 4 In the Directory area, select the save directory of the collected log information. Step 5 Click Collect to start the collection. ----End
Result
By default, the collected information is saved as a package in the path M2000 client installation directory\client\diagnosis. If an error is displayed during the decompression of the package, you need to decompress the package to a path with fewer sub-layers.
Issue 03 (2010-08-31)
15-9
16 FAQs (HA, Sun)
16
About This Chapter
FAQs (HA, Sun)
This chapter describes some frequently asked questions (FAQs) and the answers regarding the M2000 HA system. 16.1 About Solaris (HA, Sun) This section describes some FAQs and their answers regarding the Solaris operating system. 16.2 About Sybase (HA, Sun) This section describes some FAQs and their answers regarding the Sybase. 16.3 About Server Software (HA, Sun) This section describes some FAQs and their answers regarding the M2000 server software.
Issue 03 (2010-08-31)
16-1
16 FAQs (HA, Sun)
16.1 About Solaris (HA, Sun)

This section describes some FAQs and their answers regarding the Solaris operating system. 16.1.1 How Do I Log In to the M2000 Server as User root Through Telnet This section describes how to log in as user root through Telnet. 16.1.2 How to Log In the M2000 Server as the root User Through FTP This section describes how to log in as user root through the FTP. 16.1.3 How to Check the Status of the Tape Drive This section describes how to check the status of the tape drive. 16.1.4 How Should I Select a Tape Drive If there are multiple tape drives in the system, you need to select a tape drive for storing backup data. For the server that is not equipped with an internal tape drive but has an external tape drive and the server that is equipped with an internal tape drive but is not equipped with an external tape drive, the default tape drive is /dev/rmt/0. 16.1.5 How to View the Hardware Settings of the M2000 Server This section describes how to view the hardware settings of the M2000 server. 16.1.6 How to Check the Device Status of the M2000 Server This section describes the common commands used to check the device status of the M2000 server. 16.1.7 Why Unable to Enter the Domain Console of Fire E4900 This section describes the solutions to the failure to enter the domain console of the Sun Fire E4900. 16.1.8 How to Modify the Port Number of the FTP Server By default, the port number of the FTP server is 21. You need to change the port number of the FTP server according to the actual requirement. 16.1.9 How to Query the Time Zone Name This section describes how to query a time zone name. Before querying the DST rules of a time zone, you must know the name of the time zone. Based on the time zone name, you can query the corresponding DST rules. 16.1.10 How Should I Stop the NTP Service on the M2000 Server (HA) This section describes how to stop the NTP service on the M2000 server in an HA system. 16.1.11 How Do I Change the IP Address of the S3X00 Disk Array (Command Mode) This section describes how to change the IP address of the S3X00 disk array in command mode. The disk array is connected to the server directly through optical fibers. Changing IP addresses does not affect data read operations on the disk array. Therefore, you are advised to use the factory-delivered default IP address of the disk array. If the IP address of a disk array needs to be changed, change the IP address according to the actual situation. The IP address of each S3X00 disk array needs to be changed. 16.1.12 How Should I Change the IP Address of the 6140 Disk Array (Command Mode) This section describes how to change the IP address of the 6140 disk array in command mode. To change the IP address of the 6140 disk array, the server must be installed with the 6140 management host software. You need to configure each disk array. 16.1.13 How Do I Change the IP Address of the S2600 Disk Array (Command Mode)
16 FAQs (HA, Sun)
This section describes how to change the IP address of the S2600 disk array in command mode. The disk array is connected to the server directly through optical fibers. Therefore, the change of the IP address of the disk array does not affect data read operations on the disk array. You are advised to retain the factory default IP address of the disk array. If the IP address of the disk array needs to be changed, change it according to the actual situation. 16.1.14 What Should I Do When the CD-ROM Drive Cannot Read the CD-ROM This section describes why the CD-ROM drive cannot read the CD-ROM and provides the solution to this problem. 16.1.15 How to Handle the corrupt label - wrong magic number Message This section describes how to handle the corrupt label - wrong magic number message. 16.1.16 What Should I Do When the Server Disk Space Is Insufficient This section describes what to do when the server disk space is insufficient. 16.1.17 How to Configuring the Monitoring Function of the S2600 Disk Array This section describes how to configure the monitoring function of the S2600 disk array. 16.1.18 How Should I Configure the Monitoring Function for the S3000 Series Disk Arrays This section describes how to configure the monitoring function for the S3000 series disk arrays, such as S3100 and S3200. 16.1.19 How Should I Uninstall the OceanStor Monitoring Software This section describes how to uninstall the OceanStor monitoring software. 16.1.20 How Should I Check the Running Status of the FTP Service on the M2000 Server This section describes how to check the running status of the FTP service on the M2000 server. 16.1.21 How Should I Start the FTP Service on the M2000 Server This section describes how to start the FTP service on the M2000 server. 16.1.22 How Should I Check the Running Status of the SFTP Service on the M2000 Server This section describes how to check the running status of the SFTP on the M2000 server. 16.1.23 How Should I Start the SFTP Service on the M2000 Server This section describes how to start the SFTP service on the M2000 server. 16.1.24 How Do I Log In to the Server in SSH Mode This section describes how to log in to the server in SSH mode.
16.1.1 How Do I Log In to the M2000 Server as User root Through Telnet
This section describes how to log in as user root through Telnet.
Question
How do I log in as user root through Telnet?
NOTE
The following operations are only applicable to the non-security hardening system, not applicable to the security hardening system.
Issue 03 (2010-08-31)
16-3
16 FAQs (HA, Sun)
Answer
If you fail to log in to the M2000 server as user root through Telnet, you can use the following method to obtain the rights. 1. 2. Log in to the server through the system controller (SC), remote system controller (RSC), or extended system controller facility (XSCF) as user root. Run the following commands to enter the /opt directory. Then check whether the SEK subdirectory exists in the directory. # cd /opt # ls If the SEK subdirectory exists, the current system is a security hardening system, stop doing the operations; if the SEK subdirectory does not exist, the current system is not a security hardening system, continue to do the following operations. 3. Open /etc/default/login. # TERM=vt100; export TERM # vi /etc/default/login 4. 5. 6. Find CONSOLE=/dev/console. Comment this line off by adding # at the beginning of the line. Save the changes and then exit the file. Check whether the Telnet service is started. # svcs -l telnet
l
If the system output contains disable, you can infer that the Telnet service is not started. Perform 7 again. If the system output contains enabled, you can infer that the Telnet service is started successfully.
7.
Start the Telnet service. # svcadm enable telnet
16.1.2 How to Log In the M2000 Server as the root User Through FTP
This section describes how to log in as user root through the FTP.
Question
How to log in as the root user through FTP?
Answer
If you fail to use the FTP service as user root, use the following method to obtain the permission. 1. 2. Log in as user root through SSH mode. Open /etc/ftpd/ftpusers. # TERM=vt100; export TERM # vi /etc/ftpd/ftpusers 3. 4.
16-4
Find root. Comment this line off by adding # at the beginning of the line. Save, and then exit the file.
16 FAQs (HA, Sun)
16.1.3 How to Check the Status of the Tape Drive

This section describes how to check the status of the tape drive.
Question
How do I check the server tape drive status?
Answer
If a built-in tape drive is installed, the server identifies the tape drive upon startup. For an external tape drive, you must install it. To install an external Sun tape drive, such as Ultra 60, perform the following steps: 1. 2. 3. 4. 5. 6. Power off the server and all the peripherals. Set the ID switch on the tape drive to 4 or 5. If you use SCSI interface, connect the SCSI cable to the IN port on the tape drive. Switch on the server and all the peripherals and start the system. Log in as user root through SSH mode. Run the following command to check the status of the tape drive: This part takes the logical device of the tape drive, that is, /dev/rmt/0, for example. # mt -f /dev/rmt/0n status The commands mentioned earlier can be briefly written as mt status. Table 16-1 lists the output. Table 16-1 Tape drive status No. 1 Output Certance Ultrium 3 tape drive: sense key(0x6)= Unit Attention residual= 0 retries= 0 file no= 0 block no= 0 2 /dev/rmt/0n: no tape loaded or drive offline /dev/rmt/0n: No such file or directory The tape is not inserted or not identified correctly, or the inserted tape is a cleaning tape. The previous message indicates that the operating system does not detect the tape drive. Tape Drive Status The tape drive works normally. A tape is loaded and rewound.
7.
Configure the tape drive. # drvconfig # tapes
8.
Load a tape and then check the status of the tape drive. # mt status
Issue 03 (2010-08-31)
16-5
16 FAQs (HA, Sun)
16.1.4 How Should I Select a Tape Drive

If there are multiple tape drives in the system, you need to select a tape drive for storing backup data. For the server that is not equipped with an internal tape drive but has an external tape drive and the server that is equipped with an internal tape drive but is not equipped with an external tape drive, the default tape drive is /dev/rmt/0.
Question
If the system has multiple tape drives, which tape drive should be used for storing backup data?
Answer
1. Check for the number of tape drives in the system. # ls /dev/rmt
0 0b l 0bn 0c 0cb 0cbn 0cn 0h 0hb 0hbn 0hn 0l 0lb 0lbn 0ln 0m 0mb 0mbn 0mn 0n 0u 0ub 0ubn 0un
If the system output shows only the logical device files that are preceded by 0, it indicates that only one tape drive is connected. If the system output also shows the logical device files that are preceded by 1, it indicates that two tape drives are connected.
2.
Identify the type of a tape drive. Based on the number of tape drives obtained from 1, determine the type of each tape drive. # mt -f Name of the logical device config Determine the type of the first tape drive. # mt -f /dev/rmt/0 config
"HP C7438A", "HP DAT-72", "CFGHPDAT72"; CFGHPDAT72 = 2,0x34,0,0x18659,4,0x47,0x47,0x47,0x47,3,120,420,3600,36000,3600, 3600,17400;
As indicated by the command result, the type of the first tape drive is HP DAT-72G. This type of tape drive supports the 36 or 72 GB tape. This tape drive matches the logical device / dev/rmt/0. Determine the type of the second tape drive. # mt -f /dev/rmt/1 config
"CERTANCEULTRIUM 3", "Certance Ultrium 3", "CFGCERTANCEULTRIUM3"; CFGCERTANCEULTRIUM3 = 2,0x3B,0,0x18619,4,0x40,0x42,0x44,0x44,3,120,3600,2100, 3600,2100,2100,10800;
As indicated by the command result, the type of the second tape drive is Certance Ultrium 3. This type of tape drive supports the 400 or 800 GB tape. This tape drive matches the logical device /dev/rmt/1. 3. Check the status of the tape drive. Insert a tape into the tape drive and check whether the tape drive is operational. This operation takes the logical device of the tape drive, that is, /dev/rmt/0, for example. # mt -f /dev/rmt/0 status If the system output is similar to the following information, it indicates that the tape drive is functioning well:
HP DAT-72 tape drive: sense key(0x6)= Unit Attention file no= 0 block no= 0 residual= 0 retries= 0
16-6
Issue 03 (2010-08-31)
16 FAQs (HA, Sun)
If a tape is not inserted or not identified correctly, or the inserted tape is a cleaning tape, the system displays the following information:
/dev/rmt/0n: no tape loaded or drive offline
16.1.5 How to View the Hardware Settings of the M2000 Server

This section describes how to view the hardware settings of the M2000 server.
Question
How to check the Sun server hardware configuration and memory size?
Answer
To view settings about the server hardware, perform the following steps on the server: 1. 2. Log in as user root through SSH mode. Check different items by running the commands listed in Table 16-2.
Table 16-2 Checking the server configuration No. 1 2 3 4 Command # uname -aX # prtconf|grep Memory # psrinfo -v # prtdiag Output Server model and number of CPUs Memory size CPU status Check the status of the hardware.
16.1.6 How to Check the Device Status of the M2000 Server

This section describes the common commands used to check the device status of the M2000 server.
Question
Which commands are often used to check the device status?
Answer
Table 16-3 lists the commands often used for checking the device status.
Issue 03 (2010-08-31)
16-7
16 FAQs (HA, Sun)
Table 16-3 Commands for checking the device status N Item o . 1 Hard ware Confi gurati on Description Hardware configuration
Check the disk status. Check the CPU status. Check the device tree. Check the power supply.
# iostat -E # psrinfo -v # prtconf -D # prtdiag -v # ifconfig -a # kstat -p ce:0:ce0:ifspeed The network port name varies according to the configuration. # netstat -r # snoop -d ce0 The network port name varies according to the configuration.
Netw ork conn ectio n and confi gurati on
Check network configuration. Check network port speed. Check route information. Locate faults and check network port messages. Check MAC settings for the IPMP technology.
# eeprom local-mac-address?
File syste m and disk partit ionin g
Check the file system. Check disk partitioning.
# more /etc/vfstab # format Specify disk (enter its number): number of the disk partition to be checked format> p partition> p
Check system error logs.
# more /var/adm/messages | grep err
16-8
Issue 03 (2010-08-31)
16 FAQs (HA, Sun)
N Item o .
Description
Hardware configuration
Check system error log settings. Redirect logs from T3/SC/ Domain to Blade 150. Check for the Solaris version and patch. Check all Solaris patches. 4 Volu me and mirro r Check volume information. Check volume information.
Add the contents below to /etc/syslog.conf on the Blade 150:

local7.notice local0.notice local1.notice /var/adm/messages.t3 /var/adm/messages.SC /var/adm/messages.DomainA
Check messages in /var/adm.
# uname -a
# showrev -p # vxdg list This step is applicable for only the server with a disk array. # vxdisk list All hard disks are online. This step is applicable for only the server with a disk array.
Check volume information.
# vxprint -th -g ossdg The KSTATE column of pl, sd, and v is displayed ENABLED, and the STATE column is displayed ACTIVE. This step is applicable for only the server with a disk array. # cd /etc/vx/bin # vxlicrep
Check the license of Volume Manager. Check the mirror status.
# metastat
NOTE
l This command is applicable for only the servers that use SUN
DiskSuite (SDS) or Solaris Volume Manager (SVM) for encapsulating root disks.
l When the M2000 uses the T5220 server, run the raidctl command
to view the mirroring status.
Tape drive
Check the tape drive status. Rewind the tape. Forward one step.
# mt stat # mt rewind # mt fsr
Issue 03 (2010-08-31)
16-9
16 FAQs (HA, Sun)
N Item o .
Description
Forward two steps. Backward two steps. Check the tape content.
# mt fsr 2 # mt bsr 2 This part takes the the logical device of the tape drive, that is, / dev/rmt/0, for example. # gtar tf /dev/rmt/0
Copy files to the tape.
This part takes the the logical device of the tape drive, that is, / dev/rmt/0, for example. # gtar cvf /dev/rmt/0n file name
Restore files from the tape to the disk. Check the Solaris system backup. Back up the Solaris to the tape.
This part takes the the logical device of the tape drive, that is, / dev/rmt/0, for example. # gtar xvPfM /dev/rmt/0 This part takes the the logical device of the tape drive, that is, / dev/rmt/0, for example. # ufsrestore -t /dev/rmt/0n This part takes the the logical device of the tape drive, that is, / dev/rmt/0, for example. # ufsdump 0ucf /dev/rmt/0n backup folder For example: # ufsdump 0ucf /dev/rmt/0n backuprestore # ufsdump 0ucf /dev/rmt/0n /dev/vx/rdsk/rootvol
Restore operating system from tape. Configure the tape drive. 6 CD drive r Flopp y disk Configure the CD-ROM. Configure the floppy disk.
This part takes the the logical device of the tape drive, that is, / dev/rmt/0, for example. # ufsdump rvf /dev/rmt/0n # drvconfig # tapes # mount -F hsfs -o ro /dev/rdsk/c0t6d0s0 /cdrom
# volcheck # mount -F pcfs /dev/diskette/floppy
16-10
Issue 03 (2010-08-31)
16 FAQs (HA, Sun)
N Item o . 8 Ether net port log
Description
Locate the fault and export the log.
# /opt/SUNWexplo/bin/explorer Obtain the output log in the following path: /opt/SUNWexplo/output For example:
explorer.83bbbcad.osssvr-2005.08.15.02.05 explorer.83bbbcad.osssvr-2005.08.15.02.05.tar.gz
16.1.7 Why Unable to Enter the Domain Console of Fire E4900

This section describes the solutions to the failure to enter the domain console of the Sun Fire E4900.
Question
When you attempt to enter the domain console, the system displays the message that the system is busy.
Answer
The domain console allows for only one connection. If a user is already connected to the domain console, the system displays the message that the system is busy. To enter the domain console, perform the following steps: 1. 2. 3. 4. Enter the platform shell. Run the connections command to view the connection results. Run the disconnect id command to disconnect the console. Enter the console.
Example
osssvr-1-sc0:SC> connections
ID --1 8 11 Hostname ----------------------------Localhost Localhost 10.0.119.150 Idle Time --------00:01 00:01 Connected On -------------Aug 26 17:13 Aug 30 13:51 Aug 30 15:10 Connected To -------------Platform Domain A Platform
osssvr-1-sc0:SC> disconnect 8 osssvr-1-sc0:SC> connections

ID --1 11 Hostname ----------------------------Localhost 10.0.119.150 Idle Time --------00:01 Connected On -------------Aug 26 17:13 Aug 30 15:10 Connected To -------------Platform Platform
osssvr-1-sc0:SC>
16 FAQs (HA, Sun)
16.1.8 How to Modify the Port Number of the FTP Server

By default, the port number of the FTP server is 21. You need to change the port number of the FTP server according to the actual requirement.
Question
How to Change the Port Number of the FTP Server?
Answer
This part takes the change of the port number from 21 to 1234 as an example. To change the port number of the FTP server, perform the following steps: 1. 2. 3. Log in to the server as user root through SSH mode. In the HA system, you need to log in to the two nodes separately. Run the following command to modify the /etc/services file: # vi /etc/services Identify the following line, change 21 to 1234, and then run the wq! command to save and exit the vi editor:
ftp 21/tcp
4.
Run the following command to make the modification to take effect. # svcadm disable /omc/ftp:default # svcadm enable /omc/ftp:default
5. 6.
On the PC, switch to the command mode and run the ftp command. Run the following command to connect to the server through FTP. ftp> open IP address of the server 1234 Type the user name and password of user root to log in to the server.
16.1.9 How to Query the Time Zone Name

This section describes how to query a time zone name. Before querying the DST rules of a time zone, you must know the name of the time zone. Based on the time zone name, you can query the corresponding DST rules.
Question
How to query the name of a time zone?
Answer
To query the name of a time zone, perform the following steps: 1. 2. Log in to the Solaris server as user root through SSH mode. Obtain the information on the country code of the time zone. # more /usr/share/lib/zoneinfo/tab/country.tab A part of the content to be obtained from the file is as follows:
... BR Brazil
16-12
Issue 03 (2010-08-31)

CL CN ... Chile China
16 FAQs (HA, Sun)
Based on the previous information, you can confirm that the country codes of Brazil, Chile, and China are BR, CL, and CN respectively. 3. Based on country codes, obtain the information on time zone names. # more /usr/share/lib/zoneinfo/tab/zone_sun.tab
l
The format of the zone_sun.tab file is country code + longitude and latitude + time zone name + comments. The north latitude and the east longitude are considered to be positive. The south latitude and the west longitude are considered to be negative.
A part of the content to be obtained from the file is as follows:

... #country#code coordinates TZ comments BR -0351-03225 America/Noronha Brazil/DeNoronha Atlantic islands BR -0127-04829 America/Belem Amapa, E Para BR -0343-03830 America/Fortaleza NE Brazil (MA, PI, CE, RN, PB) BR -0803-03454 America/Recife Pernambuco BR -0712-04812 America/Araguaina Tocantins BR -0940-03543 America/Maceio Alagoas, Sergipe BR -1259-03831 America/Bahia Bahia BR -2332-04637 America/Sao_Paulo Brazil/East S & SE Brazil (GO, DF, MG, ES, RJ, SP, PR, SC, RS) BR -2027-05437 America/Campo_Grande Mato Grosso do Sul BR -1535-05605 America/Cuiaba Mato Grosso BR -0846-06354 America/Porto_Velho W Para, Rondonia BR +0249-06040 America/Boa_Vista Roraima BR -0308-06001 America/Manaus Brazil/West E Amazonas BR -0640-06952 America/Eirunepe W Amazonas BR -0958-06748 America/Rio_Branco Brazil/Acre Acre CL -3327-07040 America/Santiago Chile/Continental most locations CL -2709-10926 Pacific/Easter Chile/EasterIsland Easter Island & Sala y Gomez CN +3114+12128 Asia/Shanghai PRC ...
The time zone names of Brazil, Chile, and China are listed in Table 16-4. Table 16-4 Example of the matching table between countries and time zone names Coun try Time Zone Name America/ Noronha America/Belem America/ Fortaleza Brazil America/Recife America/ Araguaina America/Maceio America/Bahia
Issue 03 (2010-08-31)
Remarks Brazil/ DeNoronha Atlantic islands Amapa, E Para NE Brazil (MA, PI, CE, RN, PB) Pernambuco Tocantins Alagoas, Sergipe Bahia
16-13
16 FAQs (HA, Sun)
Coun try
Time Zone Name America/ Sao_Paulo America/ Campo_Grande America/Cuiaba America/ Porto_Velho America/ Boa_Vista America/Manaus America/ Eirunepe America/ Rio_Branco America/ Santiago Pacific/Easter Brazil/East Brazil/West Brazil/Acre Chile/ Continental Chile/ EasterIsland -
Remarks S & SE Brazil (GO, DF, MG, ES, RJ, SP, PR, SC, RS) Mato Grosso do Sul Mato Grosso W Para, Rondonia Roraima E Amazonas W Amazonas Acre
Most locations Easter Island & Sala y Gomez -
Chile
China
PRC
NOTE
The time zone names of Europe are special. All the European countries are geographically located in the east Europe, middle Europe, and west Europe. The corresponding time zone names of the east Europe, middle Europe, and west Europe are EET, MET, and WET respectively.
16.1.10 How Should I Stop the NTP Service on the M2000 Server (HA)
This section describes how to stop the NTP service on the M2000 server in an HA system.
Prerequisite
Procedure
Step 1 Run the following command on active and standby nodes to check whether the NTP service is running: # ps -ef | grep ntp

l
16 FAQs (HA, Sun)
If the system displays the following information, perform Step 2 through Step 3 to stop the NTP service.
root 24097 1 ntp.conf.cluster 0 14:38:26 ? 0:00 /usr/lib/inet/xntpd -c /etc/inet/
If no information is displayed, you can infer that the NTP service is stopped.
Step 2 Run the following command on active and standby nodes to stop the NTP service: # kill -9 process ID The example in Step 1 indicates that the process ID is 24097. Run the following command on active and standby nodes to stop the NTP service: # kill -9 24097 Step 3 Run the following command on active and standby nodes to check whether the NTP service is stopped: # ps -ef | grep ntp If the NTP service is running, perform Step 2 through Step 3 to stop it. ----End
16.1.11 How Do I Change the IP Address of the S3X00 Disk Array (Command Mode)
This section describes how to change the IP address of the S3X00 disk array in command mode. The disk array is connected to the server directly through optical fibers. Changing IP addresses does not affect data read operations on the disk array. Therefore, you are advised to use the factory-delivered default IP address of the disk array. If the IP address of a disk array needs to be changed, change the IP address according to the actual situation. The IP address of each S3X00 disk array needs to be changed.
Prerequisites
l l
Log in to the server as user root through SSH mode. The server communicates properly with the S3X00 disk array.
Background
l
Before changing IP addresses, you must familiarize yourself with the default IP address planning at delivery. Then, determine whether to reconfigure IP addresses based on the actual situation. The IP address mentioned here is only an example. Replace it with the actual IP address. If the M4000/M5000 server is used, Ethernet port nxge3 is used to connect the server and a disk array. Thus, the IP address of Ethernet port nxge3 and the IP address of the disk array must be on the same network segment. If you have changed the IP address of the disk array on a different segment, you need to change the IP address of the corresponding Ethernet port nxge3 to ensure that both changed IP addresses are on the same network segment.
l l
Issue 03 (2010-08-31)
16-15
16 FAQs (HA, Sun)
Procedure
This takes the following change as an example to describe how to change the IP address of the disk array.
l
Before the change: IP address of controller A: 192.168.8.39 IP address of controller B: 192.168.8.40
After the change: IP address of controller A: 10.10.10.39 IP address of controller B: 10.10.10.40
1. 2.
Set the temporary subnet of the server to enable the server to access the controllers. # ifconfig bge0:1 192.168.8.100 up Check whether the temporary subnet is configured properly. # ping 192.168.8.40 If the system displays the following information, then the temporary subnet is configured properly:
PING 192.168.8.40 (192.168.8.40) 56(84) bytes of data. 64 bytes from 192.168.8.40: icmp_seq=1 ttl=64 time=0.326 ms
3.
Change the IP address of controller B. # SMcli IP address of controller A -c "set controller [b] ethernetPort [1] ipAddress= New IP address of controller B gatewayIPAddress=New gateway of controller B subnetMask=New subnet mask of controller B;" In this case, IP address of controller A is 192.168.8.39, New IP address of controller B is 10.10.10.40, New gateway for controller B is 0.0.0.0, and New subnet mask of Controller B is 255.255.255.0. Run the following command: # SMcli 192.168.8.39 -c "set controller [b] ethernetPort [1] ipAddress= 10.10.10.40 gatewayIPAddress=0.0.0.0 subnetMask=255.255.255.0;" After the command is successfully executed, the IP address of controller B is 10.10.10.40.
4. 5.
Set the temporary subnet of the server again to enable the server to access the controllers. # ifconfig bge0:2 10.10.10.100 up Check whether the new IP address of controller B is set successfully. # ping New IP address of controller B In this case, run the following command: # ping 10.10.10.40 If the system displays the following information, then the temporary subnet is configured properly:
6.
Change the IP address of controller A. # SMcli IP address of controller B -c "set controller [a] ethernetPort [1] ipAddress= New IP address of controller A gatewayIPAddress=New gateway of controller A subnetMask=New subnet mask of controller A;" In this case, IP address of controller B is 10.10.10.40, New IP address of controller A is 10.10.10.39, New gateway for controller A is 0.0.0.0, and New subnet mask of Controller B is 255.255.255.0. Run the following command:
16-16
Issue 03 (2010-08-31)
16 FAQs (HA, Sun)
# SMcli 10.10.10.40 -c "set controller [a] ethernetPort [1] ipAddress= 10.10.10.39 gatewayIPAddress=0.0.0.0 subnetMask=255.255.255.0;" After the command is successfully executed, the IP address of controller A is 10.10.10.39. 7. Check whether the new IP address of controller A is set successfully. # ping New IP address of controller A In this case, run the following command: # ping 10.10.10.39 If the system displays the following information, then the temporary subnet is configured properly:
8.
(Optional) Modify the /etc/hosts file and the /etc/inet/ipnodes file of the two nodes.
NOTE
(1) Log into both the nodes as user root through SSH mode. (2) Perform the following operations on both the nodes to modify the /etc/hosts file and to replace the existing IP address of the disk array with a new one. # vi /etc/hosts After the modification, press Esc and then run the :wq! command to save the modification and exit. (3) Perform the following operations on both the nodes to modify the /etc/inet/ipnodes file. # vi /etc/inet/ipnodes
l
16.1.12 How Should I Change the IP Address of the 6140 Disk Array (Command Mode)
This section describes how to change the IP address of the 6140 disk array in command mode. To change the IP address of the 6140 disk array, the server must be installed with the 6140 management host software. You need to configure each disk array.
Prerequisite
The network connection between the server and the 6140 disk array is normal.
Context
To change the IP address of the 6140 disk array, you need to perform this operation on the server on which the 6140 management host software is installed. The 6140 management host software is generally installed on the M2000 server before delivery. When changing the IP address of the
16 FAQs (HA, Sun)
6140 disk array, ensure that the server and the 6140 disk array are on the same network segment. Then, you need to change the IP address after logging in to the management host software as user root.
NOTE
Enter the correct name of the 6140 disk array in name of the 6140 disk array in the following commands.
Procedure
1. Perform the following steps on the server to set the temporary subnet: (1) Log in to the server as user root in SSH mode. telnet IP address of the M2000 server Enter the user name and password of user root to log in to the server. (2) Check whether the server can communicate with controller A of the 6140 disk array. If the server requires to communicate with the 6140 disk array, you need to ensure that the IP address of the Ethernet port is on the same network segment as the IP address of controller A on the disk array. In the following commands, the default IP address 192.168.8.39 of the 6140 disk array is taken as an example. Replace it with the actual IP address of controller A. # ping 192.168.8.39 If the system output contains 192.168.8.39 is alive after you run the previous command, it indicates that the IP address of the server is on the same network segment as the IP address of controller A. Proceed with 3. Otherwise, you need to perform 1.3 through 1.5 to set the temporary subnet to ensure that the two IP addresses are on the same network segment. (3) Determine the name of the Ethernet port used to set the temporary subnet. When setting the temporary subnet, choose bge0 as the communication Ethernet port. Run the following command to check the name of the Ethernet port corresponding to the last IP address bound to this Ethernet port. # ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 bge0: flags=1000843<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 192.168.8.11 netmask ffffff00 broadcast 192.168.8.255 ether 0:3:ba:bb:bc:ad bge0: flags=1000842<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 1500 index 3 inet 0.0.0.0 netmask 0 ether 0:3:ba:bb:bc:ae nxge0: flags=1000842<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 1500 index 4 inet 0.0.0.0 netmask ffffff00 broadcast 0.0.0.0 ether 0:3:ba:bb:bc:af nxge3: flags=1000842<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 1500 index 5 inet 0.0.0.0 netmask 0 ether 0:3:ba:bb:bc:b0
When two or multiple IP addresses are bound to the Ethernet port, the name of the Ethernet port is displayed as bge0:X after you run the previous command. X is a number starting from 1. The displayed Ethernet port name cannot be used for setting the temporary subnet. When the X following bge0: is null, use bge0:1 as the name of the Ethernet port. In this example, the X following bge0: is null. Thus, you can use bge0:1 as the name of the Ethernet port to set the temporary subnet.
16 FAQs (HA, Sun)
(4) When setting the temporary subnet, ensure that the IP address of the server is on the same network segment as the IP address of controller A.
CAUTION
The IP address of the server must be on the same network segment as the IP address of controller A. Otherwise, the server cannot have an access to the disk array. In the following commands, the default IP address 192.168.8.39 of the 6140 disk array is taken as an example. Replace it with the actual IP address of controller A. # ifconfig bge0:1 plumb # ifconfig bge0:1 192.168.8.100 netmask 255.255.255.0 up (5) Check the setting of the temporary subnet. In the following commands, the default IP address 192.168.8.39 of the 6140 disk array is taken as an example. Replace it with the actual IP address of controller A. # ping 192.168.8.39 If the system output contains 192.168.8.39 is alive, then the setting is correct. Otherwise, perform 2 to check whether the IP address of the controller A on the 6140 disk array is correct and to set the temporary subnet again. 2. If you fail to set a temporary subnet, perform the following steps to check whether the IP address of the controller A on the 6140 disk array is correct:
NOTE
Perform the same procedure to check the IP address of controller B on the 6140 disk array.
(1) Connect the six-pinned mini DIN connector of the basic cable to the serial port connector of the controller.
NOTE
Two serial port cables are attached to the pallet of each controller.
l l
One end is the six-pinned mini DIN connector, and the other end is the basic cable of the standard 9-pinned serial port connector. Extended cables of the standard 9-pinned serial port connector are attached to both ends.
(2) Connect the nine-pinned serial extended cable from the nine-pinned connector of the basic cable to the serial port connector of the PC. (3) Choose Start > Programs (P) > Accessories > Communications > HyperTerminal on the PC. (4) In the Connection Description dialog box, enter the name of the new connection. (5) Select the PC serial port that is connected to the connector, for example, COM1. (6) Set the properties of the serial port. For details about how to set properties of a serial port, see Table 16-5. Then, click OK. Table 16-5 Setting the properties of the serial port Attribute Bit rate
Issue 03 (2010-08-31)
Attribute Value 38400

16-19
16 FAQs (HA, Sun)
Attribute Data bit Parity check Stop bit Streaming control
Attribute Value 8 none 1 none
Thus, a physical connection between the PC and the 6140 disk array is set up. (7) Press Break. The serial port responds to the request to synchronize the baud rate with the terminal.
Set baud rate: press <space> within 5 seconds
NOTE
The serial ports on the disk array request that the Break character be accepted. Set the corresponding escape sequence for the terminal, and then send the essential Break character to the controller. For instance, press Ctrl and Break at the same time to generate the Break character on certain terminal.
(8) Press the spacebar within five seconds. The serial port defines the baud rate for setup.
Baud rate set to 38400
(9) Press Break. The serial port responds with the following messages:
Press within 5 seconds: <S> for Service Interface, <BREAK> for baud rate
(10) Press S. The serial port prompts you to enter the password.
Enter Password to access Service Interface (60 sec timeout): - >
(11) Enter the password kra16wen, and then press Enter. (12) If the following message is displayed, enter 1.
(13) If the following message is displayed, enter 1.

Select Ethernet Port ============================== 1 Ethernet Port: 0 2 Ethernet Port: 1 Q Quit Enter Selection: 1
The configuration of the IP address for the selected Ethernet port is displayed. (14) If the following message is displayed, enter Q to exit.
(15) Perform 1.4 and 1.5 by using the IP address of controller A to reset a temporary subnet.
16 FAQs (HA, Sun)
3.
Run the following command on the server to log in to the management host software as user root: # /opt/SUNWsesscs/cli/bin/sscs login -h host name of the server -u root When the system displays Type your password:, enter the password of user root.
4.
Perform the following steps on the server to modify the IP address of the 6140 disk array. (1) Run the following command to check whether the 6140 disk array is registered. # /opt/SUNWsesscs/cli/bin/sscs list storage-system
Array: array.no.name
In the system output, array.no.name is the default name of the registered 6140 disk array. If the system returns the similar message, then the 6140 disk is registered. Otherwise, the 6140 disk array is not registered. (2) If the 6140 disk array is not registered, run the following command to register the disk array to the management host software through controller A. In the following commands, the default IP address 192.168.8.39 of the 6140 disk array is taken as an example. Replace it with the actual IP address of controller A. # /opt/SUNWsesscs/cli/bin/sscs add -i 192.168.8.39 registeredarray (3) Change the IP address of controller A on the 6140 disk array. In this part, the operation on the 6140 disk array whose disk array name is ST6140-1 is taken as an example. Replace the parameters in the commands with the actual parameters when changing the IP addresses of other 6140 disk arrays. # /opt/SUNWsesscs/cli/bin/sscs modify -a Name of the 6140 disk array (ST6140-1) -g IP address of the gateway -i IP address of controller A on the 6140 disk array -m subnet mask controller A (4) Set the temporary subnet again to make the IP address of the server be on the same network segment as the IP address of controller A.
CAUTION
The IP address of the server must be on the same network segment as the changed IP address of controller A. Otherwise, the server cannot have an access to the disk array. In the following commands, the modified IP address 10.70.12.12 of the 6140 disk array is taken as an example. Replace it with the actual IP address of controller A. # ifconfig ce0:1 plumb # ifconfig ce0:1 10.70.12.100 netmask 255.255.0.0 up (5) Check the setting of the temporary subnet. In the following commands, the changed IP address 10.70.12.12 of the 6140 disk array is taken as an example. Replace it with the actual IP address of controller A. # ping 10.70.12.12 If the system output contains 10.70.12.12 is alive, then the setting is correct. Otherwise, perform 4.4 to set the temporary subnet again. (6) Log in to the management host software as user root.
16 FAQs (HA, Sun)
# /opt/SUNWsesscs/cli/bin/sscs login -h host name of the server -u root When the system displays Type your password:, enter the password of user root. (7) Register the disk array to the management host software through controller A. # /opt/SUNWsesscs/cli/bin/sscs add -i 10.70.12.12 registeredarray
NOTE
In the following commands, 10.70.12.12 is the IP address of controller A. This address must be the same as that set in 4.3.
(8) Change the IP address of controller B. In this part, the operation on the 6140 disk array whose disk array name is ST6140-1 is taken as an example. Replace the parameters in the commands with the actual parameters when changing the IP addresses of other 6140 disk arrays. # /opt/SUNWsesscs/cli/bin/sscs modify -a Name of the 6140 disk array (ST6140-1) -g IP address of the gateway -i IP address of controller B on the 6140 disk array -m subnet mask controller B 5. (Optional) Modify the /etc/hosts file and the /etc/inet/ipnodes file of the two nodes.
NOTE
(1) Log in to both nodes as user root. (2) Perform the following operations on both nodes to modify the /etc/hosts file and to replace the existing IP address of the disk array with a new one: # vi /etc/hosts After the modification, press Esc, and then run the :wq! command to save the modification and exit. (3) Perform the following operations on both the nodes to modify the /etc/inet/ipnodes file: # vi /etc/inet/ipnodes
l
If the file records the existing IP address of the disk array, replace the existing IP address with the new one. After the modification, press Esc, and then run the :wq command to save the modification and exit. If the file records the new IP address of the disk array, you need not perform any modification. Press Esc, and then run the :q command to exit.
16.1.13 How Do I Change the IP Address of the S2600 Disk Array (Command Mode)
This section describes how to change the IP address of the S2600 disk array in command mode. The disk array is connected to the server directly through optical fibers. Therefore, the change of the IP address of the disk array does not affect data read operations on the disk array. You are advised to retain the factory default IP address of the disk array. If the IP address of the disk array needs to be changed, change it according to the actual situation.
16-22
Issue 03 (2010-08-31)
16 FAQs (HA, Sun)
Prerequisites
l l
Log in to the server as user root through SSH mode. The communication between the server and the two management Ethernet ports on the S2600 disk array is normal.
Contexts
l
Each S2600 disk array has an active controller and a standby controller. Each controller has one management Ethernet port. Before changing the IP address of the disk array, you must familiarize yourself with the default IP address planning at delivery. Then, determine whether to reset the IP address according to the actual situation. The IP address mentioned here is only an example. Replace it with the actual IP address. If you change the IP address of the disk array on different network segments, continue to change the IP address of the maintenance Ethernet port on the corresponding server to ensure that the two changed IP addresses are on the same network segment.
l l
Procedure
1. Run the following command to log in to controller A of the S2600 disk array in ssh mode: # ssh admin@IP address of controller A
CAUTION
The initial user name and password of the administrator are admin and 123456, respectively. To ensure the system security, you need to change the password after the initial login. 2. Run the following command to change the IP address of controller B: OceanStor: admin> chgctrlip -c b -a new IP address of controller B -s subnet mask -g gateway For example, to change the IP address of the management Ethernet port on controller B to 10.71.15.21, run the following command: OceanStor: admin> chgctrlip -c b -a 10.71.15.21 -s 255.255.255.0 -g 10.71.15.1 When the system displays the following prompt, type y.
3.
Run the following command to check whether the changed IP address is correct: OceanStor: admin> showctrlip
IP Address A 192.168.8.39 00:18:82:e2:01:57 B 10.71.15.21 00:18:82:e2:00:fb Controller Subnet Mask 255.255.255.0 255.255.255.0 Gateway 192.168.8.1 10.71.15.1 MAC Address
Issue 03 (2010-08-31)
16-23
16 FAQs (HA, Sun)
4. 5.
Run the following command to exit from controller A: OceanStor: admin> exit Run the following command to log in to controller B of the S2600 disk array in ssh mode: # ssh admin@new IP address of controller B
CAUTION
The initial user name and password of the administrator are admin and 123456, respectively. To ensure the system security, you need to change the password after the initial login. 6. Run the following command to change the IP address of controller A: OceanStor: admin> chgctrlip -c a -a IP address of controller A -s subnet mask -g gateway For example, to change the IP address of the management Ethernet port on controller A to 10.71.15.20, run the following command: OceanStor: admin> chgctrlip -c a -a 10.71.15.20 -s 255.255.255.0 -g 10.71.15.1 When the system displays the following prompt, type y.
7.
Run the following command to check whether the changed IP address is correct: OceanStor: admin> showctrlip
IP Address A 10.71.15.20 00:18:82:e2:01:57 B 10.71.15.21 00:18:82:e2:00:fb Controller Subnet Mask 255.255.255.0 255.255.255.0 Gateway 10.71.15.1 10.71.15.1 MAC Address
8.
Run the following command to exit from controller B: OceanStor: admin> exit
16.1.14 What Should I Do When the CD-ROM Drive Cannot Read the CD-ROM
This section describes why the CD-ROM drive cannot read the CD-ROM and provides the solution to this problem.
Question
After the CD-ROM is inserted into the CD-ROM drive, it fails to be read. After the command df -k is executed, no contents exist in the /cdrom directory. In the system output, the value of the capacity column corresponding to the /cdrom directory is not 100%.
Cause
The system cannot identify the partitioning of the CD-ROM drive.
16 FAQs (HA, Sun)
Solution
To rectify the fault, perform the following steps: 1. 2. Log in to the M2000 server as user root through SSH mode. Run the following commands to identify the partitioning of the CD-ROM drive again: # /etc/init.d/volmgt stop # /etc/init.d/volmgt start 3. Run the following command to check whether the CD-ROM drive can read the CD-ROM. # df -k In the system output, if the value of the capacity column corresponding to the /cdrom directory is 100%, you can infer that the CD-ROM drive can read the CD-ROM now. Otherwise, contact Huawei technical support engineers for assistance.
16.1.15 How to Handle the corrupt label - wrong magic number Message
This section describes how to handle the corrupt label - wrong magic number message.
Question
When the format command is executed, the system output contains the corrupt label - wrong magic number message. This problem occurs in newly mounted disk arrays. The cause is lack of disk labels.
Solution
Label the disks. 1. 2. 3. Log in to the M2000 server as user root through SSH mode. Run the following command to refresh the system hardware. # devfsadm -C Run the following command to check the disk information. # format The system output contains the corrupt label - wrong magic number message. 4. Perform the following operations to label logic disk partitions: (1) After you run the format command, the system displays the following information. Enter the sequence number corresponding to the logical partition on the disk array. In this example, the sequence number is 2.
Specify disk (enter its number):2
(2) Label the logical disk partitions.

l
If the logical partitions are not labeled, the system displays the following information. Enter y.
Disk not labeled. Label it now?
If the logical partitions are already labeled, the system displays the format> prompt. After you run the label command, enter y at the following prompt:
Ready to label disk, continue?
Issue 03 (2010-08-31)
16-25
16 FAQs (HA, Sun)
(3) After running the following command, repeat 4.1 and 4.2 to label the other logical partitions. format> disk 5. Exit format. format> q
16.1.16 What Should I Do When the Server Disk Space Is Insufficient

This section describes what to do when the server disk space is insufficient.
Question
You can use any of the following methods to check the server disk space:
l l l
View the message output area at the bottom of the M2000 client. If the disk partition usage reaches the threshold, you need to clear the disk space immediately. View the disk partition usage in the Hard Disk Monitoring window on the M2000 client. Run the df -k command to check the disk partition usage.
How do I do when the server disk space is insufficient?
Solution
l
If the system notifies you of the high disk space usage of the partition where the /data directory is located, do not delete or transfer any files. In this case, contact Huawei technical support engineers for assistance. If the system notifies you of the high disk space usage of the /export/home partition, see 11.2.3 Clearing the Disk Space of the M2000 Server to troubleshoot. If the system notifies you of the high disk space usage of the root partition / or /opt, perform as follows: 1. 2. 3. Log in to the M2000 server as user root through SSH mode. Run the following command to collect related information: # du -akd / | sort -nr > /tmp/du.out Transfer the information from the server to the client. (1) Switch to the command mode on the PC and run the ftp command. ftp IP address of the server (2) Enter the user name and password of user root. (3) Run the following commands to set the file paths on both the PC and the server:
l l
CAUTION
If the filepath contains a space, you need to use the DBC quotation marks to enclose the filepath. Otherwise, the system fails to identify this filepath, and accordingly, the file cannot be uploaded or downloaded. The filepath on the Windows desktop contains space characters. Therefore, do not save files on the desktop.
16-26
Issue 03 (2010-08-31)
16 FAQs (HA, Sun)
ftp> lcd save path of the collected information on the PC ftp> cd /tmp (4) Set the transfer mode to ASCII. ftp> asc (5) Transfer the collection results. ftp> get du.out After the uploading is complete, the system switches to the ftp> state. (6) Quit the ftp> state. ftp> bye 4. Send the collection results to Huawei technical support engineers.
16.1.17 How to Configuring the Monitoring Function of the S2600 Disk Array
This section describes how to configure the monitoring function of the S2600 disk array.
Question
How should I configure the monitoring function of the S2600 disk array?
Answer
Perform the following operations to configure the monitoring function of the S2600 disk array: 1. Log in to controller A of the S2600 disk array in SSH mode. # ssh admin@IP address of controller A
CAUTION
The initial name and password of the administrator user is admin and 123456, respectively. For security considerations, you are advised to change the password after you log in to the system for the first time. 2. Run the following command to check whether the disk array is set with a Trap IP address: OceanStor: admin> showtrapip
Index S26000 l IP Address 192.168.8.241 Port ID 162 Version 2
If there is no system output, you can infer that no Trap IP address is set. In this case, perform 3 to set a Trap IP address. If the system output is similar to the previous information, check whether the configurations in the system output are correct. If they are incorrect, perform 4 to modify the configurations.
3.
Run the following command to set a Trap IP address of the disk array: For example, set the Trap IP address of the disk array to 192.168.8.241. OceanStor:admin> addtrapip -a 192.168.8.241 -v 2 -p 162
Issue 03 (2010-08-31)
16-27
16 FAQs (HA, Sun)

NOTE
In the HA system, you need to set two Trap IP addresses for each disk array. The two Trap IP addresses correspond to the IP addresses of the two servers. Repeat 3 if another Trap IP addresses need to set.
4.
Run the following command to change the Trap IP address of the disk array: For example, change the Trap IP address of the disk array to 10.10.10.10. OceanStor:admin> chgtrapip -i S26000 -a 10.10.10.10 Run the following command to check whether the Trap IP address is successfully changed: OceanStor:admin> showtrapip
Index S26000 IP Address 10.10.10.10 Port ID 162 Version 2
5.
Run the following command to change the system time of the disk array: For example, change the system time to 2008-12-17/11:05:00. OceanStor: admin> chgsystime -t 2008-12-17/11:05:00
NOTE
l l
The system time of the disk array must be the same as that of the connected M2000 server. The command chgsystime is used to change the system time. The time ranges from 1970-01-01 00:00:00 to 2069-12-31 23:59:00.
6. 7.
Run the following command to log out of controller A: OceanStor: admin> exit Log in to the M2000 server as user root through SSH mode.
NOTE
In the HA system, you need to log in to both the active server and standby server of the M2000 as user root to modify the configuration file.
8.
Add the IP address of the disk array controller to the SANtricty_config.xml file. # cd /opt/OMC/resourcemonitor # vi SANtricty_config.xml
<config> <src name iorstring <src name iorstring </config> = = = = "trapsender" ip = "IP address of controller A" port = "23001" ""/> "trapsender" ip = "IP address of controller B" port = "23001" ""/>
If the IP address of the controller is incorrect in the file, replace the existing IP address with a new IP address. Then, press Esc and run the :wq command to save the modification and quit. 9. Run the following command to view the user.xml file: # vi user.xml
<snmp name = "trap"> <instance name = "san" run = "true" filepath = "SANtricty_config.xml"/> <instance name = "vcs" run = "true" filepath = "vcs_config.xml"/> <loginfo name = "debug" run = "false" filepath = "HDMonitor.debug"/> </snmp> l
If the status of san in the file is true, do not modify the file. Press Esc and run the :q command to quit. Otherwise, change the status of san to true. Then, press Esc and run the :wq command to save the modification and quit.
16-28
16 FAQs (HA, Sun)
10. Run the following commands to restart the ResourceMonitor process:

NOTE
In the HA system, you need to restart the ResourceMonitor process on both the active server and standby server.
# ps -ef | grep "ResourceMonitor"

root 10256 884 0 10:57:58 ? 0:55 /opt/OMC/bin/ResourceMonitor cmd start -ipaddr 10.71.15.31 >/dev/null 2>&1 root 20762 26443 0 16:54:48 pts/4 0:00 grep ResourceMonitor
# kill -9 10256
NOTE
In the previous command, replace the ResourceMonitor process ID 10256 with the actual value.
11. Run the following commands to restart the UdpDispatchService service:

NOTE
You need to restart the UdpDispatchService service on only active server.
# . /opt/OMC/svc_profile.sh # svc_adm -cmd restartsvc UdpDispatchService
16.1.18 How Should I Configure the Monitoring Function for the S3000 Series Disk Arrays
This section describes how to configure the monitoring function for the S3000 series disk arrays, such as S3100 and S3200.
Question
How should I configure the monitoring function for the S3000 series disk arrays?
Answer
1. 2. Log in to the server that is to be installed with the OceanStor as user root by using the WinaXe software. Install the OceanStor.
NOTE
l l
If the M2000 is configured with the management console, the OceanStor is installed on the management console. If the M2000 is not configured with the management console and port 162 on the M2000 server is not occupied, the OceanStor is installed on the M2000 server. For an HA system, you need to install the OceanStor on the standby node.
(1) Log in to http://support.huawei.com to download the OceanStor to the PC.

NOTE
l l
The version of the OceanStor is OceanStor S3100 S3200 S6800 Storage Manager for Solaris V200R002C01B024. The path for downloading the OceanStor is Software Download > Version Software > Outsourcing Product Line > IT Integrated Product > OceanStor.
(2) Decompress the SMIA-SOL-09.19.04.07.bin file in the OceanStor installation package. (3) Upload the decompressed file to the /opt directory in binary mode.
16 FAQs (HA, Sun)
ftp server IP address ftp> lcd path of the file on the PC ftp> cd /opt ftp> bin ftp> put /opt/SMIA-SOL-09.19.04.07.bin ftp> bye (4) Create a directory for saving the OceanStor installation package. # cd /opt # mkdir SMIADIR (5) Move the OceanStor installation package to the /opt/SMIADIR directory. # mv /opt/SMIA-SOL-09.19.04.07.bin /opt/SMIADIR/SMIASOL-09.19.04.07.bin.zip (6) Decompress the OceanStor installation package. # cd /opt/SMIADIR # unzip SMIA-SOL-09.19.04.07.bin.zip (7) Change the folder name. # mv \$BASE_DIR\$/ BASE_DIR (8) Install the SMruntime, SMclient, and SMutil software in sequence. # cd BASE_DIR/Resources/Platforms/SOL # pkgadd -d /opt/SMIADIR/BASE_DIR/Resources/Platforms/SOL/ SMruntime-SOL.pkg SMruntime # pkgadd -d /opt/SMIADIR/BASE_DIR/Resources/Platforms/SOL/SMclientSOL.pkg SMclient When the system displays the following prompt, type y:
Do you want to continue with the installation of <SMclient> [y,n?] y
# pkgadd -d /opt/SMIADIR/BASE_DIR/Resources/Platforms/SOL/SMutilSOL.pkg SMutil 3. Add the disk array to be monitored to the OceanStor. (1) Run the following commands to start the OceanStor management program: # cd /opt/SM9/client # ./SMclient (2) In the Select Addition Method dialog box, select Manual. (3) Click OK. (4) In the Add Storage Array dialog box, select Out-of-band management. Type the IP addresses of the two controllers of the disk array in First Controller and Second Controller, respectively. (5) Click Add to add the disk array. (6) After the disk array is added, click Out-of-band Storage Arrays. (7) Choose Edit > Configure Alerts. (8) Click the SNMP tab, as shown in Figure 16-1.
16 FAQs (HA, Sun)
Figure 16-1 SNMP tab page
(9) Type the IP address of the M2000 server in Trap destination. For an HA system, type the logical IP address of the M2000 server. (10) Click Add. (11) Wait until the typed IP address is added to the Configured SNMP addresses area in Figure 16-1, and then click OK. (12) If the Configure Mail Server dialog box is displayed, click Yes. 4. Modify the M2000 configuration file to set the monitoring parameters of the OceanStor. For an HA system, perform the operation on the active and standby nodes. (1) Log in to the M2000 server as user root. (2) Run the following command to run the environment variables of the M2000: # . /opt/OMC/svc_profile.sh (3) Run the following commands to run the monitoring script:
16 FAQs (HA, Sun)
# cd /opt/OMC/bin # ./deployHDMonitor.sh When the system displays the following prompt, type 2, and then press Enter.
============================================================= Please Select the Monitor Type: 1)--Sun Management Center(SMC) Monitor 2)--Sun ST6140/OceanStor S3000 Monitor Q|q)--Exit ============================================================= Please make a choice : 2
(4) When the system displays the following prompt, type the IP address of the server installed with the OceanStor.
Please input the IP of SANtricty server [default:127.0.0.1]: 192.168.1.1
(5) When the system displays the following prompt, type true.
Please set the flag to start SANtricty service [default:false]: true
(6) When the system displays the following prompt, type false.
Please set the flag to start VCS service [default:false]: false
When the system displays Finish to deploy Sun ST6140/OceanStor S3000 Monitor, it indicates that the monitoring parameters of the disk array are set.
NOTE
The configuration takes effect after about 15 minutes.
5.
Check whether the monitoring of the disk array is enabled. (1) Log in to the server installed with the OceanStor as user root by using the WinaXe software. (2) Run the following commands to start the OceanStor management program: # cd /opt/SM9/client # ./SMclient (3) In the displayed dialog box, click Out-of-band Storage Arrays. (4) Choose Edit > Configure Alerts. (5) Click the SNMP tab, as shown in Figure 16-1. (6) In the Configured SNMP addresses area, select the configured IP address, and then click Validate. (7) Switch to the fault alarm page of the M2000 client to view the alarm list. (8) Log in to the M2000 client. (9) Choose Monitor > Browse Alarm List to view the alarm list. If the information about the alarm whose ID is 1042 or the location information whose Description is Alert Test Message is available in the alarm list, it indicates that the monitoring of the disk array is enabled.
NOTE
Alternatively, you can check whether the monitoring of the disk array is enabled in the following way: 1. Remove the power supply cable from any disk array to be monitored. 2. Switch to the fault alarm page of the M2000 client to view the alarm list. If the information about the alarm whose ID is 1042 or the location information whose Description is Controller tray component failed is available in the alarm list, it indicates that the monitoring of the disk array is enabled.
16-32
Issue 03 (2010-08-31)
16 FAQs (HA, Sun)
16.1.19 How Should I Uninstall the OceanStor Monitoring Software

This section describes how to uninstall the OceanStor monitoring software.
Question
How should I uninstall the OceanStor monitoring software?
Answer
1. 2. Log in to the server installed with the OceanStor as user root. Run the following command to uninstall the OceanStor: # pkgrm SMutil When the system displays the following prompt, type y.
Do you want to remove this package? [y,n,?,q] y
# pkgrm SMclient When the system displays the following prompt, type y.
Do you want to remove this package? [y,n,?,q] y Do you want to continue with the removal of this package [y,n,?,q] y
# pkgrm SMruntime When the system displays the following prompt, type y.
Do you want to remove this package? [y,n,?,q] y
16.1.20 How Should I Check the Running Status of the FTP Service on the M2000 Server
This section describes how to check the running status of the FTP service on the M2000 server.
Prerequisites
Context
l l
You can use the traditional plain text mode or FTPS as the FTP transfer policy. As an FTP application based on the SSL protocol, the FTPS protocol encrypts data during FTP login connection and data transmission. The FTP service on the M2000 server adopts the self-adaptive mode. It can determine whether to use the FTPS mode or the FTP mode based on the encryption mode adopted by the FTP client. FTPS can be used between the M2000 and NEs. When FTPS is used, firewall ports 0 to 500 must be open.
Procedure
1. Run the following command to check the running status of the FTP service: # ps -ef | grep ftpd | grep -v grep If the following information is displayed, it indicates that the FTP service on the M2000 server is started. If there is no system output, start the FTP service by referring to 16.1.21 How Should I Start the FTP Service on the M2000 Server.
16 FAQs (HA, Sun)

root 26510 22906 0 19:53:39 pts/1

0:00 /usr/sbin/ftpd
In the system output, the value in the second line refers to the process ID of the FTP service on the M2000 server.
16.1.21 How Should I Start the FTP Service on the M2000 Server
This section describes how to start the FTP service on the M2000 server.
Prerequisites
Context
l l
You can use the traditional plain text mode or FTPS as the FTP transfer policy. As an FTP application based on the SSL protocol, the FTPS protocol encrypts data during FTP login connection and data transmission. The FTP service on the M2000 server adopts the self-adaptive mode. It can determine whether to use the FTPS mode or the FTP mode based on the encryption mode adopted by the FTP client. FTPS can be used between the M2000 and NEs. When FTPS is used, firewall ports 0 to 500 must be open.
Procedure
1. Run the following command to start the FTP service: # /usr/sbin/ftpd & The system displays the process ID of the FTP service. 2. Run the following command to check the running status of the FTP service: # ps -ef | grep ftpd | grep -v grep The system displays the following information:
root 26510 22906 0 19:53:39 pts/1 0:00 /usr/sbin/ftpd
In the system output, the value in the second line is the process ID of the FTP service on the M2000 server. This value must be the same as the process ID displayed in step 1.
16.1.22 How Should I Check the Running Status of the SFTP Service on the M2000 Server
This section describes how to check the running status of the SFTP on the M2000 server.
Prerequisites
Context
l
SSH FTP (SFTP), is an FTP transfer mode based on the SSH protocol. SFTP uses a mature public key mechanism or private key mechanism to encrypt the data in the network. This ensures that the data communication between two ends can be performed in an encrypted channel.
16-34

l
16 FAQs (HA, Sun)
SFTP is supported between the M2000 server and the M2000 client, and also between the M2000 and an NMS.
Procedure
1. Run the following command to check the running status of the SFTP service: # svcs -a | grep ssh The system displays the following information:
online 18:46:13 svc:/network/ssh:default
If online is displayed in the system output, it indicates that the SFTP service on the M2000 server is started. If disabled is displayed in the system output, it indicates that the SFTP service on the M2000 server is not started. For details about how to start the SFTP service, see 16.1.23 How Should I Start the SFTP Service on the M2000 Server.
16.1.23 How Should I Start the SFTP Service on the M2000 Server
This section describes how to start the SFTP service on the M2000 server.
Prerequisites
Context
l
SFTP is an FTP transfer mode based on the SSH protocol. SFTP uses a mature public key mechanism or private key mechanism to encrypt the data in the network. This ensures that the data communication between two ends can be performed in an encrypted channel. SFTP is supported between the M2000 server and the M2000 client, and also between the M2000 and an NMS.
Procedure
1. 2. Run the following command to start the SFTP service on the M2000 server: # svcadm enable svc:/network/ssh:default Run the following command to check the running status of the SFTP service: # svcs -a | grep ssh online is displayed in the system output. That is, the SFTP service on the M2000 server is started.
16.1.24 How Do I Log In to the Server in SSH Mode

This section describes how to log in to the server in SSH mode.
Question
How should you log in to the server in SSH mode?
Prerequisites
l
The Solaris operating system is already installed.

Issue 03 (2010-08-31)
16 FAQs (HA, Sun)

l
You have downloaded the PuTTY tool from http://support.huawei.com to the local PC.
Answer
1. Double-click PuTTY.exe. A dialog box is displayed, as shown in Figure 16-2. Figure 16-2 PuTTY Configuration
2. 3. 4. 5.
In the Host Name (or IP address) field, enter the IP address of the server to be logged in to. Select Protocol:SSH. Select Close window on exit:Only on clean exit. Click Open. When you open the window for the first time, the following interface is displayed, click Yes.
16-36
Issue 03 (2010-08-31)
16 FAQs (HA, Sun)
Figure 16-3 PuTTY Security Alert
6. 7.
When the system displays login as:, type a user name and then press Enter. When the system displays root@10.10.10.1's password:, type the password and then press Enter. When the system displays Last login: Wed Oct 31 11:59:36 2007 from 10.10.10.12, then the login is successful.
16.2 About Sybase (HA, Sun)

This section describes some FAQs and their answers regarding the Sybase. 16.2.1 How Do I Check Whether the Sybase Is Started This section describes how to check whether the Sybase is started. 16.2.2 How to Start the Sybase (HA, Sun) This section describes how to start the Sybase for an HA system. 16.2.3 How to Stop the Sybase (HA, Sun) This section describes how to stop the Sybase. 16.2.4 How to View the Name of the Sybase Server This section describes how to view the name of the Sybase server when the Sybase database is running. 16.2.5 How to Handle Database Alarms This section describes why database alarms are generated and how to handle these database alarms. 16.2.6 How to View Database Deadlock Information This section describes how to check the deadlock information about the Sybase database. 16.2.7 Why the Sybase Is Not Started After the Server Restarted This section describes why the Sybase is not started after the M2000 is restarted. 16.2.8 Why Is the Sybase Not Started After Run svc_profile.sh This section describes why the Sybase is not started after the execution of the script svc_profile.sh. 16.2.9 Why the Sybase Backup Database Abort This section describes how to solve the Sybase backup abort. 16.2.10 What Should I Do When the Database Cannot Be Started Properly This section describes what to do when the database cannot be started properly.
16 FAQs (HA, Sun)
16.2.11 What Should I Do When the Client Is Disconnected Due to Damaged System Tables in the Database (HA) This section describes what to do when the client is disconnected due to damaged system tables in the database. 16.2.12 What Should I Do When the Number of Database Connections Is Insufficient This section describes what to do when the number of database connections is insufficient. 16.2.13 How to Handle the '/export/home/sybdev/master.dat' already in use Message This section describes how to handle the '/export/home/sybdev/master.dat' already in use message.
16.2.1 How Do I Check Whether the Sybase Is Started

This section describes how to check whether the Sybase is started.
Question
How do I check the startup status of the Sybase?
Answer
Perform the following steps to check the status of Sybase: 1. Switch to user dbuser on the active node.
l l
Log in to the server as dbuser through SSH mode and switch to dbuser state. Run the su - dbuser command as user root. You can switch to user dbuser.
2.
Run the following commands: -bash-3.00$ cd /opt/sybase/ASE-15_0/install -bash-3.00$ ./showserver

UID PID PPID C STIME TTY TIME CMD dbuser 341 339 0 Oct 21 ? 0:01 /opt/sybase/ASE-15_0/bin/ backupserver -SSYB_back -e/opt/sybase/ASE-15_0/install dbuser 3104 3103 1 Oct 25 ? 312:20 /opt/sybase/ASE-15_0/bin/ dataserver -sSYB -d/data/master_dev.dat -e/opt/sybase/
If the output includes dataserver and backupserver, it indicates that the data service process and the backup service process of the database are already started.
NOTE
Switch to user dbuser from user root. After you check the Sybase status, run the exit to roll back to user root.
16.2.2 How to Start the Sybase (HA, Sun)

This section describes how to start the Sybase for an HA system.
Question
How to start the Sybase?
16 FAQs (HA, Sun)
Answer
To start the Sybase, perform the following steps: 1. 2. logged in to the M2000 as user root through SSH mode. Check whether the Sybase service is running. Check the Sybase service, see 16.2.1 How Do I Check Whether the Sybase Is Started. -bash-3.00$ exit 3. Run the following command: # scswitch -e -j sybase_rs
16.2.3 How to Stop the Sybase (HA, Sun)

This section describes how to stop the Sybase.
Question
How should I do to stop the Sybase?
Prerequisites
Please ensure the M2000 services is stopped.
Answer
To stop the Sybase, perform the following steps: 1. 2. logged in to the M2000 as user root through SSH mode. Run the following command stop the Sybase. # scswitch -n -j sybase_rs
16.2.4 How to View the Name of the Sybase Server

This section describes how to view the name of the Sybase server when the Sybase database is running. 1. 2. Log in to the server as user dbuser through SSH mode. Run the following command to view the name of the Sybase server: -bash-3.00$ ps -ef | grep RUN_ | grep -v grep In the command result, the value after the RUN_ is the name of the database server. As shown in the following command result, the name of the database server in this example is SYB:
16.2.5 How to Handle Database Alarms

This section describes why database alarms are generated and how to handle these database alarms.
16 FAQs (HA, Sun)
Problem Description
Alarms are generated in the M2000 database, such as the fmdb database and the pmdb database.
Cause Analysis and Solution

The alarms generated in the M2000 database are caused by lack of database space and low alarm threshold.
l
Alarms are generated in the fmdb alarm database. Cause analysis The alarm dump mechanism is not configured correctly, which leads to a scenario in which the alarm data is not dumped immediately. Alarms are generated due to lack of alarm database space. Solution Check and modify the settings for alarm data dump on the M2000 client. For details about how to check and modify the settings for alarm data dump, refer to 10.3 Clearing M2000 Databases.
Alarms are generated in the pmdb alarm database. Cause analysis The pmdb alarm database does not delete the outdated performance data in time, which leads to a scenario in which the outdated performance data is not dumped. Alarms are generated due to lack of alarm database space. Solution

Modify the configuration file on the M2000 server and restart performance services. Decrease the number of measured objects and measured counters by operating on the M2000 client. Check and modify the settings for performance data dump. For details on how to check and modify the settings for performance data dump, refer to 10.3 Clearing M2000 Databases.
Alarms are generated in the omcdb database, swmdb database, and other databases. Cause analysis

The alarm threshold is configured extremely low. The number of managed NEs exceeds the management capacity of the M2000. The data in the database is not dumped in time. Alarms are generated due to lack of database space. Modify the alarm threshold on the M2000 client. Decrease the number of the NEs under the management of the M2000. Check and modify the settings for data dump on the M2000 client. For details about how to check and modify the settings for data dump, refer to 10.3 Clearing M2000 Databases.
Solution

16.2.6 How to View Database Deadlock Information

This section describes how to check the deadlock information about the Sybase database.
16 FAQs (HA, Sun)
Question
How to check the deadlock information about the Sybase database when a fault occurs?
Answer
To view the database deadlock information, perform the following steps: 1. 2. Log in to the Solaris as user dbuser through SSH mode. Run the following commands: -bash-3.00$ isql -Sdatabase server name -Usa -Ppassword of user sa 1> sp_lock 2> go
NOTE
The class column will display the cursor name for locks associated with a cursor for the current user and the cursor id for other users. fid spid loid locktype table_id page row dbname class context ------ ------ ----------- ---------------------------- ----------- ---------------- --------------- --------------------------------------------------------0 10 20 Sh_intent 464004684 0 0 master Non Cursor Lock (1 row affected) (return status = 0)
NOTE
In the command result, Non Cursor Lock shows no dead lock is available. The database name is master,spid=10,table_id=464004684. To check further information, run the following commands:
1> dbcc traceon(3604) 2> go

DBCC execution completed. If DBCC printed error messages, contact a user with System Administrator (SA) role.
NOTE
The command output displays the traced information on the monitor.
1> use master 2> go 1> select object_name(464004684) 2> go

16 FAQs (HA, Sun)

-----------------------------spt_values (1 row affected)
1> dbcc sqltext(10) 2> go

DBCC execution completed. If DBCC printed error messages, contact a user with System Administrator (SA) role.
NOTE
The commands check the messages of spid=10,table_id=464004684 of the master database.
16.2.7 Why the Sybase Is Not Started After the Server Restarted
This section describes why the Sybase is not started after the M2000 is restarted.
Question
Why does the Sybase not start after the M2000 server restarts? This takes SYB, which is the name of the database server, as an example. Open the Sybase system log SYB.log. Find that the record similar with the following contents is available:
kernel Configuration Error: Configuration file, '/opt/sybase/ASE-15_0/SYB.cfg', does not exist. kernel Warning: A configuration file was not specified and the default file '/opt/sybase/ASE-15_0/SYB.cfg' does not exist. SQL Server creates the default file with the default configuration. kernel Configuration file '/opt/sybase/ASE-15_0/SYB.cfg' has been written and the previous version has been renamed to '/opt/sybase/ASE-15_0/SYB.076'
NOTE
Causes
The file SYB.cfg records the settings of the Sybase. If the system cannot find SYB.cfg, it creates new SYB.cfg for storing the default settings of the Sybase. The major cause is that the default values in SYB.cfg are not consistent with those required by the M2000 system. The file SYB.cfg is generated once the Sybase is installed, and this file cannot be deleted. The Sybase cannot find the file because the Sybase is not authorized to read this file. The M2000 server, after being installed, restarts the Sybase through dbuser on boot. The user account dbuser, however, is not authorized to read SYB.cfg.
16 FAQs (HA, Sun)
SYB.cfg Ownership
After the Sybase is installed, the owner of SYB.cfg is the user who has installed the Sybase, that is, dbuser in the M2000 system. If user root starts the Sybase and changes Sybase settings through isql, root becomes the owner of SYB.cfg. Thus, dbuser cannot read SYB.cfg. If dbuser starts the Sybase, dbuser remains as the owner of SYB.cfg even after root changes the Sybase settings through isql.
Solution
When the Sybase creates SYB.cfg, the Sybase renames the existing SYB.cfg as SYB.*. The specific file name is recorded in the system log of the Sybase, that is, SYB.log. In this example,SYB.cfg is renamed as SYB.076. The solution is to rename SYB.076 as SYB.cfg and reset the ownership of this file. To handle the faults, perform the following steps: 1. Log in to the active and standby nodes as user root through SSH mode. # cd /opt/sybase/ASE-15_0 # cp SYB.076 SYB.cfg # chown -R dbuser:staff /opt/sybase/ASE-15_0 # su - dbuser 2. Start the Sybase. For details, see 16.2.2 How to Start the Sybase (HA, Sun).
16.2.8 Why Is the Sybase Not Started After Run svc_profile.sh

This section describes why the Sybase is not started after the execution of the script svc_profile.sh.
Description
After you run the script svc_profile.sh in M2000 Installation Directory, the Sybase service is not started. The M2000 server default installation path is /opt/OMC.
Analysis
The M2000 needs to support multiple Sybase versions. Therefore, you need to set the value of $SYBASE in svc_profile.sh to the related folder of the M2000, such as M2000 server installation path/3rdTools/sybase. The M2000 server default installation path is /opt/OMC. You, however, must set the value of $SYBASE to the Sybase installation folder to start the Sybase service. The two settings conflict. In this case, if you set the value of $SYBASE in svc_profile.sh to the related folder of the M2000, the Sybase service fails to start.
Solution
Before you start the Sybase service, run SYBASE.sh in Sybase installation path. The Sybase default installation path is /opt/sybase/.
16 FAQs (HA, Sun)
16.2.9 Why the Sybase Backup Database Abort

This section describes how to solve the Sybase backup abort.
Question
Why does the Sybase backup database stop abnormally?
Answer
Run the nohup command before you start the Sybase. 1. 2. Log in to the Solaris as user dbuser through SSH mode. Run the following command: -bash-3.00$ cd /opt/sybase/ASE-15_0/install/ -bash-3.00$ nohup ./startserver -f ./RUN_SYB_back In the previous command, SYB is the name of the database server. In actual situations, replace this name with the real name.
NOTE
16.2.10 What Should I Do When the Database Cannot Be Started Properly

This section describes what to do when the database cannot be started properly.
Question
How do I do when the database cannot be started properly?
Cause
l
The information about server shared memory information is not set in /etc/system. The value of the set shmsys:shminfo_shmmax field in /etc/system is the server shared memory information. The value of the shared memory is x1024x1024/2, and the unit is MB. If the shared memory is not correctly set, installing the Sybase fails. Thus, the system displays a message, indicating that memory is incorrect, during the startup of the Sybase.
In the file system database, the owner of the files under the /data directory is changed. The correct owner of the database files under the /data directory is dbuser, and the user group is staff.
The owner of the /opt/sybase/ASE-15_0/SYB.cfg configuration file of the Sybase database is incorrect.
16-44
16 FAQs (HA, Sun)
The correct owner of the /opt/sybase/ASE-15_0/SYB.cfg configuration file is dbuser, and the user group is staff. # ls -l /opt/sybase/ASE-15_0/SYB.cfg
-rwxrwxrwx SYB.cfg l 1 dbuser staff 9926 Sep 2 10:50 /opt/sybase/ASE-15_0/
After the Sybase database is stopped, the /opt/sybase/SYB.krg file is not successfully deleted. After you change the IP address of the server, the IP address information recorded in the / opt/sybase/interfaces file is not changed.
NOTE
l l
SYB in the /opt/sybase/ASE-15_0/SYB.cfg and /opt/sybase/SYB.krg files is the name of the Sybase database server. Replace SYB in actual situations. On the server, run the following command. Based on the system output, obtain the name of the database server. -bash-3.00$ cd /opt/sybase/ASE-15_0/install -bash-3.00$ ls | grep RUN_SYB If the system displays the following information, you can infer that the name of the database server is SYB1:
RUN_SYB1 RUN_SYB1_back
Solution
contact Huawei technical support engineers for assistance.
16.2.11 What Should I Do When the Client Is Disconnected Due to Damaged System Tables in the Database (HA)
This section describes what to do when the client is disconnected due to damaged system tables in the database.
Question
The client is disconnected from the server. When viewing the /opt/sybase/ASE-15_0/install/ database server name.log log file, the following message is displayed:
02:00000:00344:2008/05/27 14:14:38.84 kernel infected with signal 11 (SIGSEGV) 02:00000:00344:2008/05/27 14:14:38.84 kernel Address 0x0000000080998990 Current process (0xfee0214)
(tmp_alldrop+0x84), siginfo (code, address) = (1, 0x000120003fdaa478) 02:00000:00344:2008/05/27 14:14:38.84 kernel ************************************ 02:00000:00344:2008/05/27 14:14:38.84 kernel pc: 0x0000000080f4e7b8
Issue 03 (2010-08-31)
16-45
16 FAQs (HA, Sun)

NOTE
After starting the Sybase database, run the following command to view the name of the database server. -bash-3.00$ ps -ef | grep RUN_ | grep -v grep In the system output, the value next to RUN_ refers to the name of the database server. According to the following system output, the name of the database server in this example is SYB:
Solution
The infected with signal 11 (SIGSEGV) message is in the database log file, which indicates that the system table in the master database is damaged. In this case, you need to recover the database. 1. 2. Log in to the active node as user root through SSH mode. If the M2000 services are running, stop them. For details about how to stop the M2000 services, see 9.2.4 Stopping M2000 Services (HA). 3. If the Sybase service is running, stop it. For details about how to stop the Sybase service, see 16.2.3 How to Stop the Sybase (HA, Sun). 4. Run the following command to start the data service process of the database: # su - dbuser -bash-3.00$ cd /opt/sybase/ASE-15_0/install -bash-3.00$ ./startserver -f ./RUN_SYB -m
NOTE
The startup of the database services takes about 30 seconds. Wait until the database service is started. In the previous command, SYB refers to the name of the database server. Replace SYB with the actual server name.
If the following output is displayed, press Enter.

00:00000:00001:2008/11/05 22:17:30.83 server Recovery complete. 00:00000:00001:2008/11/05 22:17:30.83 server ASE's default unicode sort order is 'binary'. 00:00000:00001:2008/11/05 22:17:30.83 server ASE's default sort order is: 00:00000:00001:2008/11/05 22:17:30.83 server 'bin_cp936' (ID = 50) 00:00000:00001:2008/11/05 22:17:30.83 server on top of default character set: 00:00000:00001:2008/11/05 22:17:30.83 server 'cp936' (ID = 171). 00:00000:00001:2008/11/05 22:17:30.83 server Master device size: 400 megabytes, or 204800 virtual pages. (A virtual page is 2048 bytes.)
5.
Run the installmaster script to recover the master database. -bash-3.00$ isql -Sname of the database server -Usa -Ppassword of user sa -i $SYBASE/ASE-15_0/scripts/installmaster When the system displays the following message, you can infer that the database is successfully recovered. Loading of master database is complete.
NOTE
Recovering the database takes about 14 minutes. Wait until the database is recovered.
6.
16-46
Run the following command to stop the data service process of the database:
16 FAQs (HA, Sun)
-bash-3.00$ isql -Sdatabase server name -Usa -Ppassword of user sa 1> shutdown 2> go -bash-3.00$ exit 7. 8. Start the Sybase database. For details, see 16.2.2 How to Start the Sybase (HA, Sun). Start the M2000 services. For details about how to start the M2000 services, see 9.2.3 Starting the M2000 Services (HA).
16.2.12 What Should I Do When the Number of Database Connections Is Insufficient

This section describes what to do when the number of database connections is insufficient.
Question
The client is disconnected from the server, and the isql is disconnected from the database. When viewing the /opt/sybase/ASE-15_0/install/SYB.log log file, the following message is displayed:
01:00000:00012:2008/05/28 01:34:38.12 server Error: 1601, Severity: 17,State: 3 01:00000:00012:2008/05/28 01:34:38.12 server There are not enough 'user
connections' available to start a new process. Retry when there are fewer active users, or ask your System Administrator to reconfigure ASE with more user connections.
NOTE
l l
SYB in the /opt/sybase/ASE-15_0/install/SYB.log files is the name of the Sybase database server. Replace SYB in actual situations. On the server, run the following command. Based on the system output, obtain the name of the database server. -bash-3.00$ cd /opt/sybase/ASE-15_0/install -bash-3.00$ ls | grep RUN_SYB If the system displays the following information, you can infer that the name of the database server is SYB1:
Solution
The database log file contains the Error: 1601 message, which indicates that the number of database connections is insufficient. You need to modify the number of database connections. 1. 2.
Issue 03 (2010-08-31)
You have logged in to the active node as user root. If the M2000 services are running, stop them.
16 FAQs (HA, Sun)
For details about how to stop the M2000 services, see 9.2.4 Stopping M2000 Services (HA). 3. 4. Switch to user dbuser. # su - dbuser Run the following commands on the active node to change the maximum number of connections to 800. -bash-3.00$ isql -Sdatabase server name -Usa -Ppassword of user sa 1> sp_configure "number of user connections", 800 2> go
l
When the system displays the following message, you can infer that the modification succeeds. Run the exit command to exit isql. Perform 5 to synchronize the modification to the standby node.
Parameter Name Default Memory Used Config Value Run Value Unit Type ------------------------------ ----------- ----------- ----------------------- -------------------- ---------number of user connections 25 350538 800 800 number dynamic (1 row affected) Resulting configuration value and memory use have not changed from previous values: new configuration value 800, previous value 800. (return status = 0)
If the system displays the following message, you can infer that the system has insufficient memory. In this case, proceed with 6.
Msg 5861, Level 16, State 1: Server 'SYB', Procedure 'sp_configure', Line 860: The current 'max memory' value '845536', is not sufficient to change the parameter 'number of user connections' to '32766'. 'max memory' should be greater than 'total logical memory' '845328' required for the configuration. (return status = 1)
5.
Run the following command to synchronize the modification to the standby node. # rcp /opt/sybase/ASE-15_0/SYB.cfg standby node name:/opt/sybase/ASE-15_0/ SYB.cfg
6.
Run the following command to check the database memory: 1> sp_configure "max memory" 2> go Then, contact Huawei technical support engineers for assistance.
16.2.13 How to Handle the '/export/home/sybdev/master.dat' already in use Message

This section describes how to handle the '/export/home/sybdev/master.dat' already in use message.
Question
The database log file /opt/sybase/ASE-15_0/install/SYB.log records the following message:
00:00000:00000:2009/10/24 23:43:08.24 kernel basis_dlock: file '/export/home/sybdev/master.dat' already in use by an ASE 00:00000:00000:2009/10/24 23:43:08.24 kernel kdconfig: unable to read primary
16-48
Issue 03 (2010-08-31)

master device 00:00000:00000:2009/10/24 23:43:08.24 server
NOTE
16 FAQs (HA, Sun)
kiconfig: read of config block failed
l l
SYB in the /opt/sybase/ASE-15_0/install/SYB.log files is the name of the Sybase database server. Replace SYB in actual situations. On the server, run the following command. Based on the system output, obtain the name of the database server. -bash-3.00$ cd /opt/sybase/ASE-15_0/install -bash-3.00$ ls | grep RUN_SYB If the system displays the following information, you can infer that the name of the database server is SYB1:
Solution
The database log file records the '/export/home/sybdev/master.dat' already in use message, which indicates that the database is started during it is running. You can ingnore the problem. Before you start the database, check whether it is already started. For details, see 16.2.1 How Do I Check Whether the Sybase Is Started.
16.3 About Server Software (HA, Sun)

This section describes some FAQs and their answers regarding the M2000 server software. 16.3.1 Why M2000 Services Restart Abnormally (HA, Sun) This section describes the solution to abnormal restart of the M2000 service in the M2000 HA system. 16.3.2 Why M2000 Services Stop Abnormally (HA, Sun) This section describes the solution to abnormal termination of the M2000 services in the M2000 HA system. 16.3.3 Why M2000 Services Fail to Start After the Server Restarts (HA, Sun) This section describes the solution to the failure to start the M2000 after the server is restarted. 16.3.4 How Do I Copy the Backup Dynamic Data from a Hard Disk to a Tape (HA, Sun) For an HA system, if you want to copy the dynamic data to a tape, it is recommended that you manually copy the backup data from the hard disk to a tape after the dynamic data is backed up on a hard disk. 16.3.5 How Do I Copy the Backup Dynamic Data from a Tape to a Hard Disk (HA, Sun) In an HA system, if the backup dynamic data is copied to a tape, you need to copy the data from the tape to the hard disk before restoring the data. 16.3.6 How Do I Verify the Dynamic Data Backed Up on a Tape This section describes how to check the validity of the dynamic data backed up on a tape in order to determine whether the data can be read properly. 16.3.7 How to Set the M2000 Administration Console as the Intermediary-Layer NTP Server (In Encryption Mode) This section describes how to set the M2000 administration console to synchronize time with the upper-layer server in encryption mode. After the setting, the M2000 administration console
16 FAQs (HA, Sun)
can function as the time source of the lower-layer server, and the M2000 server and NEs can synchronize time with the administration console in encryption mode. 16.3.8 How Do I Check the Running Status of the NTP Services on the Administration Console (In Encryption Mode) After setting the administration console as the intermediary-layer NTP server in encryption mode, you need to check the running status of the NTP services on the administration console to ensure that they are running properly. 16.3.9 How to Set the M2000 Server as the NTP Client (HA, in Encryption Mode) This section describes how to set the M2000 server as the NTP client and synchronize time with the upper-layer time server in encryption mode in an M2000 HA system. 16.3.10 How to Check the Running Status of the NTP Service on the M2000 Server (HA, in Encryption Mode) This section describes how to check the running status of the NTP service after the M2000 server is set as the NTP client in encryption mode so that the proper running of the NTP services can be ensured. 16.3.11 How Should I Handle an Incremental Backup Failure This section describes the causes of the failure to back up the M2000 dynamic data incrementally. This section also describes how to solve this problem. 16.3.12 How Should I Periodically Monitoring the CPU, Memory, and Disk The M2000 periodically exports the report of system performance, such as CPU usage, memory usage, and disk usage. Based on the report, you can analyze the load and performance of the hardware system. 16.3.13 How Should I Power On the T5220 Server Through the Serial Port of the SC This section describes how to power on the T5220 server through the serial port of the SC.
16.3.1 Why M2000 Services Restart Abnormally (HA, Sun)

This section describes the solution to abnormal restart of the M2000 service in the M2000 HA system.
Question
Why does the M2000 service restart abnormally?
Answer
The possible causes are as follows:
l l
Sybase fault M2000 system fault
To solve this problem, perform the following steps: 1. 2. 3. Log in to the server as user root through SSH mode. Run the following command to stop the M2000 service: # scswitch -n -j ossapp_rs Run the following command to stop the Sybase:. # scswitch -n -j sybase_rs
16 FAQs (HA, Sun)
4.
Set Sybase parameters. To set the parameter total memory of the database and how to modify the file RUN_SYB, refer to the software installation manual related to each server type.
5. 6. 7.
Restart the Sybase. # scswitch -e -j sybase_rs Start the M2000 service. # scswitch -e -j ossapp_rs Check system logs. Check system logs. For details, see 8.2 Querying the System Logs of the M2000.
16.3.2 Why M2000 Services Stop Abnormally (HA, Sun)

This section describes the solution to abnormal termination of the M2000 services in the M2000 HA system.
Question
1. 2. Switch to the M2000 installation path. The default M2000 installation path is /opt/OMC. # cd /opt/OMC Run the following commands: # . ./svc_profile.sh # svc_adm -cmd status If the value after not running in the output is greater than 0, the M2000 services stop abnormally.
Answer
The possible causes are as follows:
l l
An error occurs during the program running. Startup is stopped manually.
To solve this problem, perform the following steps: 1. 2. Log in to the server as user root through SSH server. Stop the services and then start the services. # scswitch -n -j ossapp_rs # scswitch -e -j ossapp_rs Do not manually stop the startup process. 3. If the problem persists, contact Huawei technical support engineers for assistance.
16.3.3 Why M2000 Services Fail to Start After the Server Restarts (HA, Sun)
This section describes the solution to the failure to start the M2000 after the server is restarted.
16 FAQs (HA, Sun)
Question
Shut down the HA system by running the command /usr/cluster/bin/scshutdown. After the active and standby nodes restart, the M2000 services are not started automatically.
Answer
If the resources are shut down before the server restarts, you must start the resources manually. To solve this problem, you can perform either of the following steps:
l l
Set the enabled attribute of the M2000 resources to True before you shut down the servers. Run the command scswitch -e -j ossapp_rs to manually restart the M2000 resources after the servers restart.
16.3.4 How Do I Copy the Backup Dynamic Data from a Hard Disk to a Tape (HA, Sun)
For an HA system, if you want to copy the dynamic data to a tape, it is recommended that you manually copy the backup data from the hard disk to a tape after the dynamic data is backed up on a hard disk.
Prerequisites
l l l
The dynamic data is backed up to a hard disk. Tapes for saving the dynamic data is available. Before using tapes to back up data, ensure that the tapes are writable.
CAUTION
You need not perform the following steps on the standby node.
Procedure
1. 2. 3. 4. 5. 6. Insert a tape into the tape drive. Log in to the node where you need to perform the steps as user root through SSH mode. Check the status of the tapes. For details, see 16.1.4 How Should I Select a Tape Drive and 16.1.3 How to Check the Status of the Tape Drive. Set the M2000 environment variables. # . /opt/OMC/svc_profile.sh Rewind the tapes. # mt -f /dev/rmt/0n rewind Backup the /export/home/backup/omc directory to a tape. # gtar cPfM /dev/rmt/0n /export/home/backup/omc (1) If one tape cannot save all the data, the following message is displayed. In such a case, you need to remove the tape from the tape drive. For details, see the manual delivered with the tape drive.
16 FAQs (HA, Sun)
Prepare volume #2 for '/dev/rmt/0' and hit return:

NOTE
You can also remove the tape by opening a new remote login window and then running the following command: # mt -f /dev/rmt/0 offline
(2) After inserting a new tape, press Enter to continue the backup. 7. When the backup is complete, you need to remove the tape from the tape drive. For details, see the manual delivered with the tape drive. After the tape is ejected, remove it from the tape drive. 8. 9. (Optional) Check the validity of the dynamic data that is backed up on the tapes. For details, see 16.3.6 How Do I Verify the Dynamic Data Backed Up on a Tape. After the check, enable write protection on the tapes, label them, and store them properly. For the naming conventions of backup tapes, see 12.1.2 Policies of M2000 Data Backup. For details about how to enable the write protection on tapes, see the hardware description of the tapes.
16.3.5 How Do I Copy the Backup Dynamic Data from a Tape to a Hard Disk (HA, Sun)
In an HA system, if the backup dynamic data is copied to a tape, you need to copy the data from the tape to the hard disk before restoring the data.
Prerequisites
CAUTION
You need not perform the following steps on the standby node.
Procedure
1. 2. 3. Insert the tape that stores dynamic data into the tape drive. If the backup dynamic data is saved on multiple tapes, insert the first tape into the tape drive. Rewind the tape. # mt -f /dev/rmt/0n rewind Restore the data from the tape to the hard disk. # /usr/sfw/bin/gtar xvPfM /dev/rmt/0n (1) Press the button on the tape drive to remove the tape when the following information is displayed. For details, see the manual delivered with the tape drive. Prepare volume #2 for '/dev/rmt/0' and hit return:
16 FAQs (HA, Sun)

NOTE
You can also remove the tape by opening a new remote login window and then running the following command: # mt -f /dev/rmt/0 offline
(2) After inserting a new tape into the tape drive, press Enter to continue the restore. 4. 5. When the restore is complete, remove the tape from the tape drive. For details, see the manual delivered with the tape drive. Change the right and owner of the /export/home/backup directory. # chmod -R 770 /export/home/backup # chown -R omcuser:omcsysm /export/home/backup
16.3.6 How Do I Verify the Dynamic Data Backed Up on a Tape

This section describes how to check the validity of the dynamic data backed up on a tape in order to determine whether the data can be read properly.
Prerequisites
l
The tape drive is operational. If an external tape drive is connected, ensure that the tape drive is properly connected to the server. You have logged in to the server as user root through SSH mode.
Background
CAUTION
l
When you use the BRT tool to check the validity of data backup, you can check whether the data in the tapes can be read, but cannot check whether the backup data can be used for restore. If the original data for backup is faulty, the data may fail to be used for restore even if it is verified to be valid. The type of the server used for data verification can be different from that used for data backup. The tape drives configured on different servers, however, may be different. Thus, it is recommended that you verify the data on the same server where the data is backed up.
Procedure
1. 2. 3. 4. Insert the tape storing the dynamic data into the tape drive. If backup data is stored on multiple tapes, insert the first one. Set the environment variables of the M2000. # . /opt/OMC/svc_profile.sh Rewind the tape. # mt -f /dev/rmt/0n rewind Verify the backup data stored on the tape. # gtar tPfM /dev/rmt/0n (1) Press the button on the tape drive to remove the tape when similar information is displayed. For details, see the manual delivered with the tape drive.
16 FAQs (HA, Sun)
Prepare volume #2for '/dev/rmt/0' and hit return:

NOTE
You can also remove the tape by opening a new remote login window and running the following command: # mt -f /dev/rmt/0 offline
(2) Insert another tape and press Enter to continue the verification. If the displayed system output contains no error information after the command is executed, it indicates that the dynamic data on the tape is valid. 5. After the verification is complete, press the button on the tape drive to remove the tape. For details, see the manual delivered with the tape drive.
16.3.7 How to Set the M2000 Administration Console as the Intermediary-Layer NTP Server (In Encryption Mode)
This section describes how to set the M2000 administration console to synchronize time with the upper-layer server in encryption mode. After the setting, the M2000 administration console can function as the time source of the lower-layer server, and the M2000 server and NEs can synchronize time with the administration console in encryption mode.
Prerequisite
l l
You have configured the upper-layer NTP server in encryption mode. You have obtained the identifier, key type, and authentication code of the upper-layer NTP server. The time zone, date, and time of the M2000 administration console are correctly set. You have logged in to the M2000 administration console as user root through SSH mode.
l l
Context
l l
Normally, the M2000 server is set as the NTP client. If no server is available to be set as the intermediary-layer time server, set the administration console of the M2000 system, that is, the Netra 240 server, to be the intermediary-layer time server. The upper-layer time server of the M2000 administration console requires that the NTP protocol must be used. The server running on the Windows operating system uses the SNTP protocol. Thus, it cannot be used as the upper-layer time server of the M2000 administration console.
Procedure
1. Run the following commands to edit the /etc/inet/ntp.keys file: # TERM=vt100; export TERM # vi /etc/inet/ntp.keys Add the identifier, key type, and authentication code of the upper-layer NTP server to the file according to the following syntax: At the same time, you can define the authentication code required for synchronizing the time between a lower-layer NTP client and the current server. Write only one data item in each line. identifier key type authentication code
16 FAQs (HA, Sun)

NOTE
l l
An identifier refers to a positive integer ranging from 1 to 4294967295. Each line in the file must contain one unique identifier. A key type is a character and refers to the encryption algorithm for calculating NTP services. S refers to the DES algorithm in standard format, N refers to the DES algorithm in NTP format, A refers to the ASCII algorithm, and M refers to the MD5 algorithm. An authentication code is used as the input parameter corresponding to an algorithm. The format of an authentication code depends on the corresponding algorithm.
2. 3.
Save the ntp.keys file and exit the vi editor. After editing the file, press Esc, and then run the :wq! command to save the file and exit. Run the following commands to open the /etc/inet/ntp.conf file: # cp /etc/inet/ntp.server /etc/inet/ntp.conf # TERM=vt100; export TERM # vi /etc/inet/ntp.conf
4.
In front of server 127.127.XType.0, add server IP address of the upper-layer NTP server key identifier prefer to specify the IP address and identifier of the upper-layer NTP server.
NOTE
prefer indicates that the IP address of the NTP server is synchronized preferentially. If multiple upper-level NTP servers exist, add multiple lines. Ensure that each line maps to one NTP server. For example,
server IP address of upper-layer NTP server 1 key identifier 1 prefer server IP address of upper-layer NTP server 2 key identifier 2
5.
Change XType in server 127.127.XType.0 and fudge 127.127.Xtype.0 stratum 0 to 1. The value 1 indicates that the local host functions as the standard time source. Delete stratum 0 from fudge 127.127.1.0 stratum 0. In front of broadcast 224.0.1.1 ttl 4, add # to comment out this line to disable the broadcast mode. Delete 0 from trustedkey 0 to add the identifier of the upper-layer NTP server and the identifier used by the NTP client for synchronizing time with the current server. Separate the two identifiers with a space. Add enable auth to the file. After editing the file, press Esc, and then run the :wq! command to save the file and exit.
6. 7. 8.
9.
10. Save the ntp.conf file and exit the vi editor. 11. Run the following command to modify the rights of the ntp.keys file and the ntp.conf file: # chmod 400 /etc/inet/ntp.keys # chmod 400 /etc/inet/ntp.conf
Task Instance
Assume that the administration console synchronizes the upper-layer time servers whose IP addresses are 10.161.94.212 and 10.161.94.214, the upper-layer time server uses the MD5 algorithm, the identifiers are 5 and 3, and the corresponding authentication codes are tPol3kRS and l2082skt. Assume that the MD5 algorithm is used, the identifier is 12, and the authentication code is k0ssL09a during the synchronization of the time between the client and the current server.
16 FAQs (HA, Sun)
The contents of the created /etc/inet/ntp.keys file are as follows:

5 M tPol3kRS 3 M l2082skt 12 M k0ssL09a
The contents of the /etc/inet/ntp.conf file before the modification are as follows:
server 127.127.XType.0 fudge 127.127.XType.0 stratum 0 broadcast 224.0.1.1 ttl 4 keys /etc/inet/ntp.keys trustedkey 0
The contents of the /etc/inet/ntp.conf file after the modification are as follows:
server 10.161.94.212 key 5 prefer server 10.161.94.214 key 3 server 127.127.1.0 fudge 127.127.1.0 #broadcast 224.0.1.1 ttl 4 keys /etc/inet/ntp.keys enable auth trustedkey 5 3 12
Postprocessing
After setting the M2000 administration console as the intermediary-layer NTP server, you need to start the NTP services on the administration console. For details, see 4.5.3 Starting the NTP Service on the M2000 Administration Console.
16.3.8 How Do I Check the Running Status of the NTP Services on the Administration Console (In Encryption Mode)
After setting the administration console as the intermediary-layer NTP server in encryption mode, you need to check the running status of the NTP services on the administration console to ensure that they are running properly.
Context
After the NTP server and client are started, the system requires five minutes for system test. Wait for about five minutes, and then run the ntpq -p command and the ntptrace command to query the status of the NTP services. During system test, if you run the ntpq -p command, the displayed address of the remote time source does not contain *. If you run the ntptrace command, the system displays Timeout or Not Synchronized.
Procedure
1. 2. You have logged in to the M2000 administration console as user root through SSH mode. Run the following command to view the information about the time source: # ntpq -p In the result of the ntpq -p command, the remote field shows the address and status of the time source of the M2000 server. 3. Run the following command to check the information about the clock synchronization path: # ntptrace
16 FAQs (HA, Sun)
The ntptrace command traces the NTP synchronization path from the host to the top-layer NTP server. For details, run the ntptrace -v command. 4. Run the following command to check the status of NTP authentication: # ntpq ntpq> as The system output is similar to the following information:
ind assID status conf reach auth condition last_event cnt =========================================================== 1 28852 f614 yes yes ok sys.peer reachable 1
In the system output, if auth is ok, it indicates that the NTP services are successfully authenticated. ntpq> exit
Task Instance
The administration console functions as the intermediary-layer NTP server. # ntpq -p
remote refid st t when poll reach delay offset disp ============================================================================== *10.71.15.69 .LCL. 1 u 13 64 377 0.56 -0.730 0.06 LOCAL(0) LOCAL(0) 3 l 12 64 377 0.00 0.000 10.01
# ntptrace
localhost: stratum 2, offset 0.000043, synch distance 0.02032 10.71.15.69: stratum 1, offset -0.000714, synch distance 0.01007, refid 'LCL'
# ntpq ntpq> as
ind assID status conf reach auth condition last_event cnt =========================================================== 1 15820 f614 yes yes ok sys.peer reachable 1 2 15821 9014 yes yes none insane reachable 1
ntpq> exit *10.71.15.69 in the result of the ntpq -p command indicates that the IP address of the NTP server that the host is synchronized with is 10.71.15.69. The value 1 in the st column indicates that the host is located at stratum 1. The symbol * indicates that the NTP services are running properly. The result of the ntptrace command indicates that the host is located at stratum 2, that the IP address of the upper-level server is 10.71.15.69, and that the upper-level server is at stratum 1. Run the ntpq command, and then type as. If auth is ok, it indicates that the authentication between the host and the upper-layer NTP server is successful.
16.3.9 How to Set the M2000 Server as the NTP Client (HA, in Encryption Mode)
This section describes how to set the M2000 server as the NTP client and synchronize time with the upper-layer time server in encryption mode in an M2000 HA system.
16 FAQs (HA, Sun)
Prerequisite
l l
You have configured the upper-layer NTP server in encryption mode. You have obtained the identifier, key type, and authentication code of the upper-layer NTP server. The time zone, date, and time of the active and standby nodes are correct. Log in to the active and standby nodes as user root through SSH mode.
l l
Context
The upper-layer time server of the M2000 server requires that the NTP protocol must be used. The server running on the Windows operating system uses the SNTP protocol. Thus, it cannot be used as the upper-layer time server of the M2000 server.
Procedure
1. If the M2000 services are running, run the following command on the active node to stop them: # scswitch -n -j ossapp_rs 2. Run the following command on the active and standby nodes to check whether there is any system output: If there is no system output, you can infer that the M2000 daemon process is stopped. # . /opt/OMC/svc_profile.sh # daem_ps 3. 4. If the daemon process is still running, run the following command to stop it: # kill_daem If the Sybase services are running, run the following command on the active node to stop them: # scswitch -n -j sybase_rs 5. Run the following commands on the active and standby nodes to edit the /etc/inet/ ntp.keys file: # TERM=vt100; export TERM # vi /etc/inet/ntp.keys Add the identifier, key type, and authentication code of the upper-layer NTP server to the file according to the following syntax. Write only one data item in each line. identifier key type authentication code
NOTE
l l
An identifier refers to a positive integer ranging from 1 to 4294967295. Each line in the file must contain one unique identifier. A key type is a character and refers to the encryption algorithm for calculating NTP services. S refers to the DES algorithm in standard format, N refers to the DES algorithm in NTP format, A refers to the ASCII algorithm, and M refers to the MD5 algorithm. An authentication code is used as the input parameter corresponding to an algorithm. The format of an authentication code depends on the corresponding algorithm.
6.
Save the ntp.keys file and exit the vi editor. After editing the file, press Esc, and then run the :wq! command to save the file and exit.
Issue 03 (2010-08-31)
16-59
16 FAQs (HA, Sun)
7.
Run the following commands on the active and standby nodes to edit the ntp.conf.cluster file: # TERM=vt100; export TERM # vi /etc/inet/ntp.conf.cluster The correct ntp.conf.cluster configuration file contains the following contents:
peer clusternode1-priv prefer peer clusternode2-priv
If you use the NTP server specified by the operator, you need to add server IP address of the upper-layer NTP server key identifier next to server 127.127.1.0 in the ntp.conf.cluster configuration file. Add multiple lines if multiple NTP servers exist. 8. Add the following contents to the ntp.conf.cluster configuration files of the active and standby nodes:
enable auth keys /etc/inet/ntp.keys trustedkey N
N in the last line refers to the identifier used for NTP authentication. If multiple upper-layer NTP servers exist, write the identifiers of these servers in one line. Separate the identifiers with spaces. For example, trustedkey 3 4 9. Save the ntp.conf.cluster file and exit the vi editor. After editing the file, press Esc, and then run the :wq! command to save the file and exit. 10. If the Sybase services are stopped in 4, run the following command on any node to start them: # scswitch -e -j sybase_rs 11. If the M2000 services are stopped in 1, run the following command on any node to start them: # scswitch -e -j ossapp_rs 12. Run the following command on a standby node to check whether there is any system output: # . /opt/OMC/svc_profile.sh # daem_ps
l l
If there is any system output, you can infer that the daem process is started. If there is no system output, you can infer that the daem process is not started. Run the following commands to start it: # start_daem -type standby
13. Run the following command on the active and standby nodes to check the system date and time: # date If the system date and time of the two nodes are different, contact Huawei technical support engineers for assistance.
Postprocessing
After setting the M2000 server as the NTP client, you need to start the NTP services on the server. For details, see 4.5.6 Starting the NTP Service on the M2000 Server (HA).
16 FAQs (HA, Sun)
16.3.10 How to Check the Running Status of the NTP Service on the M2000 Server (HA, in Encryption Mode)
This section describes how to check the running status of the NTP service after the M2000 server is set as the NTP client in encryption mode so that the proper running of the NTP services can be ensured.
Context
After the NTP server and the NTP client are started, the system requires five minutes for the system test. Wait for five minutes and then run the ntpq -p and ntptrace commands to query the status of the NTP service. During the system test, if you run the ntpq -p command, the displayed address of the remote clock source does not contain *. If you run the ntptrace command during the system test, the system displays Timeout or Not Synchronized.
Procedure
1. 2. Log in to both the nodes as user root through SSH mode. Run the following command to query the information about clock source: # ntpq -p In the result of the ntpq -p command, the remote field shows the address and status of the reference clock source. 3. Run the following command on node 1 to check the NTP synchronization path: # ntptrace The ntptrace command traces the NTP synchronization path from the host to the top NTP server. For more information, run the ntptrace -v command. 4. Run the following command on node 1 to check the authentication status of the NTP service: # ntpq ntpq> as In the result, the value ok of auth indicates the NTP service is successfully authenticated. ntpq> exit 5. Repeat 2 to 4 on node 2 to check the running status of the NTP service on node 2.
16.3.11 How Should I Handle an Incremental Backup Failure

This section describes the causes of the failure to back up the M2000 dynamic data incrementally. This section also describes how to solve this problem.
Problem
The M2000 dynamic data fails to be backed up incrementally.
Cause
The causes of the incremental data backup failure are as follows:
l
The database logs are not consecutive.

Issue 03 (2010-08-31)
16 FAQs (HA, Sun)

l
The disk space is insufficient.
Solution
l
The database logs are not consecutive. 1. Check the backup and restore log. -bash-3.00$ more /opt/OMC/var/logs/backup.log If the log contains truncate-only transaction dump has been performed, it indicates that the database logs are truncated manually. If the log contains non-logged operation, it indicates that a manual operation is performed on the database so that the database does not record event logs. 2. Perform a full backup again. For details, see 12.2.3 Manually Backing Up the M2000 Dynamic Data (HA).
The disk space is insufficient. 1. Check the backup and restore log. -bash-3.00$ more /opt/OMC/var/logs/backup.log If the log contains the following information, it indicates that the backup space is insufficient.
The free disk space is low ,give up buck! The free disk space of /export/home/ is low. Give up backup!
2.
Clear the disk space of the M2000 server. For details, see 16.1.16 What Should I Do When the Server Disk Space Is Insufficient.
3.
Perform a full backup again. For details, see 12.2.3 Manually Backing Up the M2000 Dynamic Data (HA).
16.3.12 How Should I Periodically Monitoring the CPU, Memory, and Disk
The M2000 periodically exports the report of system performance, such as CPU usage, memory usage, and disk usage. Based on the report, you can analyze the load and performance of the hardware system.
Prerequisite
Log in to the M2000 server as user omcuser through SSH mode. In the HA system, log in to the active node.
Context
The 3-second period is used for sampling the CPU and the memory and the 1-minute period is used for monitoring disks. The difference between the monitoring of the clients and the monitoring of the server is that the monitoring on the client can export the usage of the CPU, memory, and disks only at certain time. The monitoring on the server, however, can export the periodically sampled usage of the CPU, memory, and disks.

l
16 FAQs (HA, Sun)
The CPU and the memory performance report file records performance reports in the following format:
Hostname, Time, CPU Occupancy(%), MEM Occupancy(%), Physical Memory(MB), Remaining Physical Memory(MB), Swap Memory(MB), Remaining Swap Memory(MB)
The disk usage report file records disk usage reports in the following format:
Hostname, Time, Partition Name, Total Size(MB), Used Size(MB), Remaining Size(MB), Used Rate(%), IO Rate(%)
Procedure
Step 1 Switch to the default installation path of the M2000 server software. The default installation path of the M2000 server software is /opt/OMC. -bash-3.00$ cd /opt/OMC Step 2 Run the environment variant commands. -bash-3.00$ . ./svc_profile.sh Step 3 Enable the function of exporting reports.
l
Enable the function of exporting a performance report. -bash-3.00$ svc_monitor -cmd start -type system Enable the function of exporting a disk usage report. -bash-3.00$ svc_monitor -cmd start -type disk
The performance report is saved as a .csv file in M2000 server installation path/var/monitor/ sysinfo. The default file name is sysinfo. The disk usage report is saved as a .csv file in M2000 server installation path/var/monitor/diskinfo. The default file name is diskinfo. Step 4 View the exported reports.
l
View the performance report. -bash-3.00$ cd M2000 server installation path/var/monitor/sysinfo -bash-3.00$ more Performance report file name
Check the report about disk usage. -bash-3.00$ cd M2000 server installation path/var/monitor/diskinfo -bash-3.00$ more Disk usage report file name
----End
16.3.13 How Should I Power On the T5220 Server Through the Serial Port of the SC
This section describes how to power on the T5220 server through the serial port of the SC.
Question
How should I power on the T5220 server through the serial port of the SC?
Answer
Before powering on the server, ensure that the following conditions are met:
16 FAQs (HA, Sun)

l l l
The SC of the server is configured. The communication between the PC and the Ethernet port on the server SC is normal. The password of user admin of the SC is available.
Perform the following steps: 1. Start the PuTTY on the PC terminal and set up the connection between the PC and the SC based on the SSH protocol. In the PuTTY Configuration window, select SSH, enter IP address of the SC in Host Name (or IP Address), and then click Open to log in to the SC.
NOTE
l l
Log in to the http://support.huawei.com to download the PuTTY to the PC. If the PC and SC cannot be connected through the PuTTY, connect them by using a serial port cable. For details, see the corresponding software initial installation guide.
2. 3. 4.
Enter the user name admin and the password to log in to the SC. The sc> prompt is displayed. Run the following command to power on the server: sc> poweron Run the console command, and then press Enter to connect the server.
NOTE
After the console command is executed, if the system displays Console session already in use. [view mode], it indicates that you have not logged out of the console last time. In this case, run the console -f command to connect the server. When the system displays a confirmation message, type y, and then press Enter.
If the Solaris operating system is not installed, the system is switched to the ok state after the T5220 is started. If the Solaris, Sybase, or M2000 server software is correctly installed, the system automatically starts the Solaris, Sybase, or M2000 server software after the T5220 is started.
16-64
Issue 03 (2010-08-31)

M2000 HA System Administrator Guide (Sun, S10)

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

M2000 HA System Administrator Guide (Sun, S10)

Caricato da

Copyright:

Formati disponibili

M2000 V200R010

HA System Administrator Guide (Sun, S10)

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HA System Administrator Guide (Sun, S10)

About This Document

About This Document

Description The content descriptions are changed.

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

About This Document

HA System Administrator Guide (Sun, S10)

Description The content descriptions are changed. New added.

HA System Administrator Guide (Sun, S10)

About This Document

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

About This Document

HA System Administrator Guide (Sun, S10)

HA System Administrator Guide (Sun, S10)

About This Document

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HA System Administrator Guide (Sun, S10)

2 Powering the M2000 On or Off (HA).....................................................................................2-1

3 Managing Cluster Resources of the M2000 (HA).................................................................3-1

4 Setting the M2000 Time (HA)..................................................................................................4-1

5 Configuring the IP Address of the M2000 Server (HA)......................................................5-1

HA System Administrator Guide (Sun, S10)

6 Managing the M2000 Clients...................................................................................................6-1

7 Managing the M2000 Users (HA)............................................................................................7-1

8 Managing OSS System (HA)...................................................................................................8-1

HA System Administrator Guide (Sun, S10)

9 Managing the M2000 Processes and Services (HA).............................................................9-1

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HA System Administrator Guide (Sun, S10)

10 Managing the M2000 Databases..........................................................................................10-1

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

11 Managing the M2000 Files and Disks (HA)......................................................................11-1

12 Backing Up and Restoring the M2000 (HA)......................................................................12-1

13 M2000 Routine Maintenance (HA).....................................................................................13-1

HA System Administrator Guide (Sun, S10)

14 M2000 Emergency Maintenance (HA)................................................................................14-1

15 Troubleshooting the M2000.................................................................................................15-1

15.3 Collecting Fault Data Using the Log Information Collector.......................................................................15-7

16 FAQs (HA, Sun)......................................................................................................................16-1

HA System Administrator Guide (Sun, S10)

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HA System Administrator Guide (Sun, S10)

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HA System Administrator Guide (Sun, S10)

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HA System Administrator Guide (Sun, S10)

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HA System Administrator Guide (Sun, S10)

1 M2000 High Availability System

M2000 High Availability System

About This Chapter

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

1 M2000 High Availability System

HA System Administrator Guide (Sun, S10)

1.1 Features and Working Principles of the HA System

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HA System Administrator Guide (Sun, S10)