550-06484 EMS 9.3 Installation and Upgrade Guide PDF

EMS 9.
3 Installation and Upgrade Guide
Element Management System
For the latest documentation, please visit https://support.sonus.net
Sonus Technical Publications Part Number: 550-06484

http://www.sonus.net Document Version: 1
Software Version: 09.03.00R000
Copyright © 2015 Sonus Networks. All rights reserved. Page 1

Disclaimer
This document presents information for users of the products of Sonus Networks, Inc. ("Sonus"), its affiliates and its subsidiaries (collectively, the "Sonus Group"). Network Equipment
Technologies, Inc. and Performance Technologies, Incorporated are part of the Sonus Group. The Sonus Group does not assume any liability arising out of the application or use of any
product or circuit described herein. No part of this document may be copied or reproduced in any form or by any means without the prior written permission of Sonus. For the most current user
documentation, please contact your Sonus customer support representative.
Copyright
Copyright © 1999 - 2015 Sonus Networks, Inc. All rights reserved. Printed in the U.S.A. This item and the information contained herein are the property of the Sonus Group. This publication
may be used, copied, or distributed only in accordance with the terms of the license agreement. Any other use, reproduction, or distribution may occur only upon Sonus' prior written consent.
Third-Party Copyrights
Open BSD Copyright (c) 1982, 1986, 1990, 1991, 1993. The Regents of the University of California. All rights reserved. THIS SOFTWARE IS PROVIDED BY THE REGENTS AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the above disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the disclaimer in the documentation and/or other materials provided with the
distribution.
3. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
Disclaimer and Restrictions
The information in this document may be used by customers solely for the use and understanding of the Sonus Group's products and solutions. This document is not meant to define an
interface between products of the Sonus Group and any third party hardware or software. The Sonus Group reserves the right to change the design and implementation used for any of the
tables, screens, field names, etc. to enhance its products as it sees fit.
Warranties
THIS INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING,BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. REFERENCES TO CORPORATIONS, THEIR SERVICES AND PRODUCTS, ARE
PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED. IN NO EVENT SHALL THE SONUS GROUP BE LIABLE FOR ANY SPECIAL,
INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES OF ANY KIND, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER OR
NOT ADVISED OF THE POSSIBILITY OF DAMAGE, AND ON ANY THEORY OF LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
INFORMATION.
Descriptions of, or references to, products, services or publications within the Sonus Group's documentation do not imply endorsement of that product, service or publication. Sonus Networks
makes no warranty of any kind with respect to the subject matter included herein, the products listed herein, or the completeness or accuracy of the information. Sonus Networks specifically
disclaims all warranties, express, implied or otherwise, including without limitation, all warranties of merchantability and fitness for a particular purpose.
THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES MAY BE PERIODICALLY MADE TO THE INFORMATION HEREIN.
Trademarks
Sonus Networks, the Sonus Networks logo, Open Services Architecture, Insignus, SMARRT, Sonus Networks Insight, IMX, GSX9000, GSX4000, GSX4010, SBC 5100TM, SBC 5200TM, IMX,
SBC9000, the Atreus logo, the Performance Technology, Inc. logo, Insight xAuthority, Monterey 8000, NexusWare, SEGway and SIP Xpress are either registered trademarks or trademarks of
Sonus Networks, Inc. Open Services Partner Alliance and Sonus Networks CARE are service marks of Sonus Networks, Inc. The Sonus Group trademarks may not be used in connection with
any product or service that is not the Sonus Group's in any manner that is likely to cause confusion among customers or in any manner that disparages or discredits the Sonus Group. All other
product names mentioned herein are trademarks, service marks, registered trademarks, or registered service marks of their respective owners.
Third-Party Trademarks
Apache is the http server, and Tomcat is the Servlet/JSP container developed by the Apache Software Foundation. — Rapid Service Introduction (RSI) System is a trademark of BayPackets,
Inc. — Borland is a registered trademark, and AppServer is a trademark of Borland Software Corporation. — Dot Hill and SANnet are trademarks of Dot Hill Systems Corp. — Eclipse is a

trademark of Eclipse Foundation, Inc. GoAhead and SelfReliant are registered trademarks of GoAhead Software, Inc. — IBM, Netcool, Rational, ClearCase, and WebSphere are registered
trademarks of International Business Machines Corporation in the United States, other countries, or both. — Intel, Xeon, and Pentium are registered trademarks of Intel Corporation in the
United States and/or other countries. — Iomega is a registered trademark of the Iomega Corporation, a wholly owned subsidiary of the EMC Corporation. — Macromedia is a registered
trademark, and JRun is a trademark of Macromedia, Inc. in the U.S. and/or other countries. — DataDirect is a registered trademark of Progress Software Corporation. — Linux is a registered
trademark of Linus Torvalds in the United States and/or other countries. — Microsoft, Microsoft Internet Explorer logo, Windows, Windows NT, Windows XP, and/or other Microsoft products
referenced herein are either registered trademarks or trademarks of Microsoft Corporation in the U.S. and/or other countries. — MySQL is a registered trademark of MySQL AB in the United
States, the European Union and other countries. — Netscape is a registered trademark of Netscape Communications Corporation in the U.S. and other countries. — Nokia is a registered
trademark of Nokia Corporation. — Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates. — Palm OS and Palm Powered are
registered trademarks, and Palm is a trademark owned by or licensed to Palm, Inc. — Red Hat, RPM, JBoss, and all Red Hat-based trademarks are trademarks or registered trademarks of
Red Hat, Inc. in the United States and/or other countries. — Sage Instruments is a copyright of Sage Instruments, Inc. — Service Availability and the Service Availability logo are trademarks
used with the permission of their owner. — SnowShore, SnowShore Networks, and N20 are trademarks of Cantata Technology Inc. — SSH is an IETF protocol and OpenSSH is a derivative of
the original and free ssh 1.2.12 release by Tatu Ylonen. SSH Secure Shell is a trademark of SSH Communications Security Corp. — Sun, Sun Microsystems, Java, JumpStart, Netra, Solaris,
Solstice DiskSuite, and all trademarks that contain Sun, Solaris, or Java are trademarks, registered trademarks, or service marks of Sun Microsystems, Inc. in the United States and other
countries. — iPlanet is a division of Sun Microsystems, Inc. — All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the
U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. — Telcordia is a registered trademark and LERG is a
trademark of Telcordia Technologies, Inc. in the United States, other countries, or both. — Signalware is a registered trademark of Ulticom, Inc. — UNIX is a registered trademark in the United
States and other countries, exclusively licensed through X/Open Company, Ltd. — VeriSign is a registered trademark, and Thawte Consulting is a wholly owned subsidiary of VeriSign, Inc. —
Veritas is a trademark of Symantec Corporation or its affiliates in the U.S. and other countries. — WebLogic is a registered trademark of BEA Systems, Inc.
All other product names mentioned herein are trademarks, service marks, registered trademarks, or registered service marks of their respective owners.
FCC Compliance
This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to Part 15 of the FCC Rules. These limits are designed to provide reasonable
protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio frequency energy and, if not
installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause
harmful interference in which case the user will be required to correct the interference at the user's own expense.
Compliance with Applicable Laws and Export Control Laws
Use of the information in this publication is governed by all applicable federal, state, and local laws. All information available in this publication is subject to U.S. export control laws and may
also be subject to the laws of the country where you reside. Sonus Networks makes no representation that the content on this site is appropriate or available for use in other locations, and
access to it from territories where the content is illegal and prohibited.
All Sonus Networks, Inc. products and publications are commercial in nature. Use, duplication, or disclosure by the United States Government is subject to the restrictions set forth in DFARS
252.227-7013 and FAR 52.227-19.
Embedded Software
Oracle Enterprise Edition is an embedded part of the Sonus Group product line. The programs included herein are subject to a restricted use license and can only be used in conjunction with
this application. You are not allowed to navigate or modify the underlying database schema unless explicitly authorized in writing by Sonus.
Export Laws
Sonus Group product documentation includes technical information developed in the United States that may be subject to limitations on export imposed by the U.S. Department of State and
the U.S. Department of Commerce. All use, distribution, and transfer of any technical information shall be in compliance with U.S. export laws and regulations.

1. Introduction and Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Introduction to Insight EMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Installing and Upgrading Insight EMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Insight EMS Linux Installation and Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Hardware Requirements and Network Connectivity Information . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Installing and Upgrading Standalone EMS on Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.3 Installing and Upgrading EMS High Availability on Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.2.4 Installing and Upgrading Insight Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
2.2.5 Additional EMS Installation and Upgrade Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
2.2.6 Common EMS Administrative Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
2.2.7 EMS Installation (Linux) Quick Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
2.2.8 EMS Upgrade (Linux) Quick Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
2.3 Insight EMS SWe Installation and Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
2.3.1 Introducing Insight EMS Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
2.3.2 Installing and Upgrading Insight EMS SWe on KVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
2.3.3 Installing and Upgrading Insight EMS SWe on VMWare ESXi . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
2.3.4 Installing Insight Application Server on Virtualized Environment . . . . . . . . . . . . . . . . . . . . . . . . . . 581
2.3.5 Performing EMS Post-Installation Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
2.4 Insight EMS Solaris Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
2.4.1 Upgrading Standalone EMS on Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
2.4.2 Upgrading High Availability (HA) EMS on Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729
2.4.3 Upgrading Disaster Recovery (DR) EMS on Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1046
2.5 Installing and Upgrading Device Manager (DM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1503

Introduction and Getting Started
This section provides an introduction to Sonus Insight Element Management System (EMS) and how to search
information in online documentation.
Table of Contents
Introduction to Insight EMS
Searching Information in Online Documentation
EMS Server Based Documentation:

Linux Platform | Solaris Platform
EMS SWe Documentation:

KVM Platform | VMware ESXi Platform

Introduction to Insight EMS
Sonus EMS, is a Web-based Element Management System ( EMS) that provides a graphical user interface (GUI)
for managing Session Border Controllers (SBC), Gateway Server (GSX), BGCF Routing Server (BRX), Riverstone,
Diameter Signalling Controller (DSC), PSX Policy Server (PSX), Data Stream Integrator (DSI), Access Server
(ASX), Access Directory Server (ADS), and Signalling Gateway (SGX).
Device Type Expansion Device Variants
GSX Gateway Server GSX 9000
SBC Session Border Controllers SBC 1000, SBC 2000, SBC 5x00, SBC 7x00, SBC SWe
Riverstone Riverstone Riverstone
SGX Signalling Gateway SGX 2000, SGX 4000
ASX Access Server ASX
DSI Data Stream Integrator DSI SWe
DSC Diameter Signalling Controller DSC, DSC SWe
BRX BGCF Routing Server BRX
PSX Policy Server PSX, PSX SWe
ADS Access Directory Server ADS
Figure 1: Sonus EMS

Installing and Upgrading Insight EMS
The EMS Installation and Upgrade section is organized based on the server-based (Linux and Solaris platform) and
virtualized environments. Within the server-based and virtual environments, the content is further organized based
on the EMS deployment scenarios.
The EMS Software Release V09.03.00 on Solaris platform, only supports SalesForce upgrade to V09.03.00.
The Jumpstart USB installation or upgrade is not supported for EMS Software Release V09.03.00 on
Solaris. To use EMS Software Release V09.03.00, perform an upgrade using SalesForce.
Table of Contents
Overview
Insight EMS Linux Installation and Upgrade

Hardware Requirements and Network Connectivity Information
Installing and Upgrading Standalone EMS on Linux
Installing and Upgrading EMS High Availability on Linux
Installing and Upgrading Insight Application Server
Additional EMS Installation and Upgrade Procedures
Common EMS Administrative Tasks
EMS Installation (Linux) Quick Reference
EMS Upgrade (Linux) Quick Reference
Insight EMS SWe Installation and Upgrade

Introducing Insight EMS Virtualization
Installing and Upgrading Insight EMS SWe on KVM
Installing and Upgrading Insight EMS SWe on VMWare ESXi
Installing Insight Application Server on Virtualized Environment
Performing EMS Post-Installation Tasks
Insight EMS Solaris Upgrade

Upgrading Standalone EMS on Solaris
Upgrading High Availability (HA) EMS on Solaris
Upgrading Disaster Recovery (DR) EMS on Solaris
Installing and Upgrading Device Manager (DM)

Overview
In this section:
Supported Hardware Platforms

Server-based Environment
Virtualized Environment
EMS Deployment Configurations
EMS Standalone Deployment Configuration
EMS High-Availability (HA) Deployment Configuration
EMS Standalone Deployment for DR Configuration
EMS HA Deployment for Disaster Recovery (DR) Configuration
EMS HA-Standalone Deployment for DR Configuration
This section provides a quick overview of the supported hardware platforms for server-based and virtualized
environments and the EMS deployment configurations.
Supported Hardware Platforms
EMS can be installed on server-based and virtualized environments.
Server-based Environment
The following platforms are supported in server-based environment.
HP DL380p G8 or G8+ Server running Red Hat Enterprise Linux 6.4 or above
SUN Netra T5220 Server running Solaris 10
Virtualized Environment
The following platforms are supported in virtualized environment:
x86_64 Compatible Server running Red Hat Enterprise Linux 6.4 or above (with KVM version 0.10.2 or above
on the host).
x86_64 Compatible Server running VMware ESXi version 5.1.0 or above
EMS Deployment Configurations
The EMS can be deployed in a Standalone or High Availability (HA) configuration for both server-based and
virtualized environments.
EMS Standalone Deployment Configuration

EMS Standalone (SA) deployment is installing an EMS on a SA system and a single EMS system monitoring other
network elements.
EMS High-Availability (HA) Deployment Configuration

The EMS HA deployment configuration consists of two EMS systems to provide high-availability of services. The

EMS HA consists of one primary EMS server and one secondary EMS server. The EMS HA feature is implemented
through the use of a pair of SA EMS systems with a common RAID. In this scenario, the EMS database is stored on
RAID Disk Arrays or on a SAN. The database is constantly updated by the Primary server with details pertaining to
the network devices getting monitored, fault monitoring, alarms or traps details, and configuration details of network
devices. The database is common and can be accessed by the Primary and secondary EMS Servers. If due to
some reason, the Primary EMS server goes down, the Secondary server becomes the Primary EMS server and
fetches the configuration details from the RAID arrays.
EMS Standalone Deployment for DR Configuration

EMS standalone systems deployed in geographically different locations (source and target DR sites) and configured
to work as Disaster Recovery setup is called EMS Standalone Deployment for DR configuration.
EMS HA Deployment for Disaster Recovery (DR) Configuration

Two EMS HA setups deployed in geographically different locations (source and target DR sites) and configured to
work as Disaster Recovery setup is called is called EMS HA Deployment for Disaster Recovery (DR).
EMS HA-Standalone Deployment for DR Configuration

The DR source-site deployed with two EMS HA systems and DR target-site deployed with a single EMS SA system
and both sites configured to work as Disaster Recovery setup is called EMS HA-Standalone Configuration for DR
Setup.
The EMS HA-SA deployment for DR configuration is not supported for Linux platform.
Term Explanation
Standalone An EMS Standalone system consisting of a single node.

(SA)
High An EMS High Availability system consisting of two nodes. Also referred to as HA RAC Cluster.
Availability
(HA)
Disaster A Disaster Recovery setup consisting of a Source site and a Target site. Each site will consist of 1 node in case
Recovery of SA, and 2 nodes in case of HA.
(DR)
Source DR site consisting of Primary Database, where EMS server is up and running. This site replicates all database
changes to the target site.
Target DR site passively receiving changes from a remote source site, until a switchover happens, resulting in a DR
role swap - source becomes target and vice-versa.

Primary Refers to node 1 in case of an EMS HA setup. This is configured during the initial HA EMS installation, and does
Node not change once install is complete.
To detect whether current node is primary for EMS Linux HA , run this command as root user:
# grep "^_node01=`hostname`" /etc/rac.conf
To detect whether current node is primary for Solaris Linux HA , run this command as root user:
# cd /export/home/ems/conf/HA/
# ./hamgmt getstate
If you see any output from the above command, then you are logged in to the primary node.
Primary Refers to the database instance on the Source site. This database is in read-write mode and replicating changes
DB to the target (standby) database.
Standby Refers to the database instance on the Target site. This database is not in read-write mode, and receives
DB database changes from the source (primary) database.
DR A DR switchover is a planned role reversal between the Source (Primary DB) and the Target (Standby DB) DR
Switchover sites to avoid downtime during scheduled maintenance on the Source (Primary DB) or to test readiness for
future role transitions.
DR A DR failover is an unplanned operation performed when the source DR site goes offline for some reason and
Failover you need to promote the target DR site into a fully functional EMS.

Insight EMS Linux Installation and Upgrade
This section provides information on how to install and upgrade EMS Linux on a HP DL380p G8 or G8+ Server.
Table of Contents

Installing the EMS Application
Prerequisites for Installing EMS Standalone
Pre-Installation Checklist for EMS Standalone
Steps for Installing EMS Standalone Configuration
Configuring DR on EMS Standalone
Upgrading the EMS Application
Upgrading EMS - An Overview
EMS Standalone Upgrade Prerequisites
Downloading Upgrade Files
Steps for Upgrading EMS Standalone Using ISO INPLACE Upgrade
Steps for Upgrading EMS Standalone Using ISO Kickstart Upgrade
Steps for Upgrading EMS Standalone for DR Configuration
Performing Post-Upgrade Tasks
Rollback EMS SA
Migrating EMS Standalone from Solaris to Linux Platform
Steps for Migrating EMS Standalone from Solaris to Linux Platform
Steps for Migrating EMS Standalone DR from Solaris to Linux Platform

Installing EMS High Availability Configuration
Prerequisites for Installing EMS HA on Linux
Pre-Installation Checklist for EMS High Availability Configuration
Steps for Installing EMS High Availability Configuration
Configuring DR on EMS HA
Upgrading EMS on High Availability Configuration
Upgrading EMS HA Configuration - An Overview
Prerequisites for EMS HA Upgrade
Downloading the Software Bundle for EMS HA Upgrade
Steps for Upgrading EMS HA Using ISO Upgrade
Steps for Upgrading EMS HA for DR Configuration
Post-Upgrade Steps
Rollback EMS HA
Migrating from EMS HA Solaris or Pre-EMS 9.1 HA Linux
Migrating from Pre-EMS 9.1 HA Linux to New HA Linux Configuration
Migrating from Solaris to Linux HA
Migrating Data from StorageTek or IBM DS3524 RAID to IBM 3700 RAID
Migrating Data from Sun Solaris with StorageTek RAID or IBM DS3524 to HP G8 on Linux
with IBM V3700 RAID
Migrating from IBM DS3524 RAID (HP G8 System on Linux) to IBM V3700 RAID
Troubleshooting EMS HA on Linux

Prerequisites for Installing IAS
IAS Installation Procedure on Linux
IAS Remote Install Procedure
Starting and Stopping an IAS
Obtaining the Status of an IAS
Configuring Insight IPv4 or IPv6 Address on the IAS
Changing the Hostname and IPv4 or IPv6 Address of the IAS
Enabling API Licenses on IAS
Enabling and Disabling HTTP access on IAS server
Upgrading IAS on Linux
Upgrading Firmware on IAS
Uninstalling IAS

Performing Post-Installation or Upgrade Tasks
Common Post Installation or Upgrade Tasks for SA and HA
Standalone Specific Post-Installation or Upgrade Tasks
HA Specific Post-Installation or Upgrade Tasks
Managing Insight Account Names and Passwords
Default Account Names and Passwords
Procedures for Changing Passwords
Configuring IPv6
Enable IPv6 on the Insight EMS
Enable IPv6 on the Insight EMS HA
Update the Device with the IPv6 Management Address from the EMS Node Registration
Window
Network Connection Scenarios for Installing ISO Image
Local Installation scenario with PC or Laptop on the same Network as the iLO
Local Installation using a Laptop Directly Connected to the Server Through iLO Port
Procedure to Connect Windows XP Laptop Directly to Server iLO
Remote Installation
Managing Security Settings

Common Administrative Tasks for SA and HA
Disk Mirroring
Standalone Specific Administrative Tasks
Insight Server Administration
Insight Server System Backup and Restore
Insight Server Database Administration
Configuring Netcool
Changing Netcool DB Object Server Name for EMS SA
High Availability (HA) Specific Administrative Tasks
EMS Server Administration for HA Linux
High Availability Insight Server Administration-HA Linux
Changing Netcool DB Object Server Name
Insight Server Database Administration for EMS HA
EMS DR Operations
Setup
Switchover
Failover
Resume
Teardown
Status
Trap Notification
EMS Logs

EMS Standalone Installation
EMS High Availability (HA) Installation
DR Configuration

EMS Standalone Upgrade
ISO Upgrade
SA Post-Upgrade Tasks
EMS High Availability Upgrade
ISO Upgrade for HA
Increasing ASM Partition Size - Optional
HA Post-Upgrade Checks
EMS DR Upgrade
In this section:
Hardware Requirements
Hardware Cabling and Network Connectivity Information
Disk Partitioning Requirements for Standalone Configuration
RAID Hardware Requirements
IBM DS3524 Storage Requirements used with HP DL380p G8
IBM Storwize V3700 Storage Requirements used with HP DL380p G8
Disk Partitioning for HA Configuration
Installing HP DL380 G8 Fibre Channel Card
Software Requirements
This section provides information on hardware requirements, cabling and connectivity information for EMS.
You can procure the commercial HP ProLiant DL380p Gen8 Server directly from HP resellers or procure the OEM
long-life HP Proliant DL380p Gen8 Server from Sonus.
For more information on hardware requirements and procurement options, see Server Configurations section in HP
ProLiant DL380p Gen8 Server Quick Start. For PDF version, download HP ProLiant DL380p Gen8 Server Quick
Start PDF (550-06234).
Hardware Cabling and Network Connectivity Information
For identifying the HP ProLiant DL380p Gen8 Front and back panel components and information on cabling,
network connections and interfaces configuration, see HP DL380p Gen8 Front and Back Panel Component
Identification and Cabling and Network Connectivity for Insight EMS Standalone and EMS HA Cabling and
Connectivity in the HP ProLiant DL380p Gen8 Cabling and Network Connectivity Reference.
EMS HA does not support double failures, especially cable pullout. If both the cables are unplugged (eth0
and eth4) then it may lead to unpredictable behavior of EMS and EMS may not function properly. Avoid,
unplugging both the cables connected to eth0 and eth4 simultaneously.
Disk Partitioning Requirements for Standalone Configuration
The following table provides information about the mount points during the Insight Standalone installation:

Table 1: Disk Partitioning for Insight SA
Mount Point Partition Type Full Path of Mount Point Size (GB)
/boot RAID /dev/sda1 1
/ LVM /dev/mapper/vg00-lv.root 10
/var LVM /dev/mapper/vg00-lv.var 50
/usr LVM /dev/mapper/vg00-lv.usr 10
/opt LVM /dev/mapper/vg00-lv.opt 200
/tmp LVM /dev/mapper/vg00-lv.tmp 10
/home LVM /dev/mapper/vg00-lv.home 35
/home2 LVM /dev/mapper/vg11-lv.home2 50
/opt/oracle LVM /dev/mapper/vg11-lv.oracle 250
/swap LVM /dev/mapper/vg00-lv.swap Total Physical Memory+2GB
RAID Hardware Requirements
This section provides RAID hardware requirements information for an EMS HA.
Table 2: EMS HA Configuration
Scenario Configuration
EMS HA You can use either IBM DS3524 RAID or IBM Storwize V3700 Storage system as a RAID to store the
configuration EMS configuration, the Netcool DB and other reports.
IBM DS3524 storage array configured with:
(9) 300 GB hard disk drives

(2) 4-port Fibre Channel card
OR
IBM Storwize V3700 RAID storage system configured with:
IBM Storwize V3700 SFF Dual Control Enclosure

(9) 300GB 15000 rpm 6Gb SAS 2.5 inch HDD
(2) 8Gb Fibre Channel (FC) 4 Port Host Interface Card
IBM DS3524 Storage Requirements used with HP DL380p G8
When used with the HP DL380p G8 server in a high availability configuration, the IBM DS3524 Storage System
must meet the following requirements:

Table 3: IBM DS3524 Storage System Hardware Requirements
Component Specification (standard Sonus configuration)
Host Interface Four 8 Gb/s Fibre Channel ports per controller
Disk Drives 9 x 300 GB 10K 2.5-inch HDD installed in slots 1-9
RAID RAID-1+0
Two hot-swap DC or AC power supplies,
Dual hot-swap controllers
2 GB battery protected cache per controller
IBM Firmware Controller 07.83.27.00

or
07.77.20.00
NVSRAM N1746D35R1070V90
IBM DS Storage Manager Host Software Versions:

10.83.x5.23 (Linux)
For IBM RAID with controller firmware version 7.83, unlike the version 7.77, there is no error code with
“clear” coming from the RAID. Therefore, the issue traps coming from this RAID will remain so without
getting cleared. It has to be cleared manually.
IBM Storwize V3700 Storage Requirements used with HP DL380p G8
When used with the HP DL380p G8 server in a high availability configuration, the IBM Storwize V3700 Storage
System must meet the following requirements:
Table 4: IBM DS3524 Storage System Hardware Requirements
Enclosure IBM Storwize V3700 SFF Dual Control Enclosure (AC/DC)
Host 2 x 8Gb FC 4 Port Host Interface Card

Interface
Disk Drives 9 x 300GB 2.5in 15K rpm 6Gb SAS HDD
RAID RAID 1+0
IBM
Controller For more detail about latest IBM V3700 firmware supported and how to perform firmware
Firmware upgrade, refer the section IBM Storwize V3700 Firmware Upgrade Quick Start.
Disk Partitioning for HA Configuration

The following table provides information about the mount points during the Insight HA installation when using an IBM
DS3524 or IBM V3700 RAID:
Table 5: Disk Partitioning for Insight HA
Mount Point Partition Full Path of Mount Point Size

Type (GB)
/boot RAID /dev/sda1 1
/ LVM /dev/mapper/vg00-lv.root 10
/var LVM /dev/mapper/vg00-lv.var 50
/usr LVM /dev/mapper/vg00-lv.usr 10
/opt LVM /dev/mapper/vg00-lv.opt 200
/tmp LVM /dev/mapper/vg00-lv.tmp 10
/home LVM /dev/mapper/vg11-lv.home 30
/opt/oracle LVM /dev/mapper/vg11-lv.oracle 64
/export/home LVM /dev/mapper/vg11-lv.export.home 95
/ora_arch LVM /dev/mapper/vg11-lv.ora_arch 100
/opt/sonus/ems/weblogic/sonusEms/data LVM /dev/mapper/vg11-lv.ems.data 90
Installing HP DL380 G8 Fibre Channel Card
For Linux HA solution, Fibers channel cards are required. For more details, about how to install the Fibre channel
cards (FCC) on existing G8 servers, see the section Installing HP DL380 G8 Fibre Channel Card of HP ProLiant
DL380p Gen8 Server Quick Start.
The following are the Insight EMS software platform version requirements:
If you have upgraded to EMS V09.03.00, you can verify if EMS is upgraded to V09.03.00 by executing the
command rpm -qa SONSems:
# rpm -qa SONSems
SONSems-V09.03.00-R000.x86_64

Table 6: Insight EMS Software Requirements
Component Specification
HP Firmware For more information about HP firmware version and procedure to upgrade the HP firmware, refer the
page https://support.sonus.net/display/ALLDOC/HP+DL380p+G8+Firmware+Upgrade.
iLO Firmware
HP ProLiant
System ROM
HP Array
Controller
Firmware
Insight EMS V09.03.00

Agent Software
Java Server 1.7.0_79 (*)

version
Java Client 1.7.0_72, 1.8.0_45 (*)

version
(1)The Java Server installation happens along with the EMS ISO installation. You can execute the java
-version command and rpm -qa | grep -i jdk to check the Java Server version already installed on
the HP G8 box.
[root@ins22332 ~]# java -version

java version "1.7.0_79"
OpenJDK Runtime Environment (rhel-2.5.5.1.el6_6-x86_64 u79-b14)
OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode)
[root@ins22332 ~]# rpm -qa | grep -i jdk

java-1.7.0-openjdk-1.7.0.79-2.5.5.1.el6_6.x86_64
java-1.7.0-openjdk-devel-1.7.0.79-2.5.5.1.el6_6.x86_64
The minimum Java Client Version support for EMS and PSX Manager is 1.7.0_72. The EMS and PSX
application is tested with above version. But the application will work with 1.7.0_72 and above version also. If
you don't have the latest Java Client version, you will get warnings messages in the browser and from the
plugin.

This section provides information on installing and upgrading standalone EMS system on Linux platform.
Table of Contents


Rollback EMS SA

This section provides information on installing standalone EMS system on Linux platform. This section also provides
information on configuring DR for EMS Standalone.
Table of Contents
Before you install the EMS software, review the following prerequisites:
Download the latest EMS Documentation from

https://support.sonus.net/display/ALLDOC/Insight+EMS+Documentation.
To know about the important and late-breaking information on the EMS release, read the latest EMS Release
Notes that supplements the main documentation.
Sonus recommends that you view the warning notices pertaining to this release to see if your software or
hardware platforms are affected. If you have an account on the Sonus Salesforce Customer Portal, you can

find the warning notices at https://
c.na8.visual.force.com/apex/SolutionList?sfdc.tabName=01r80000000Q04H. If you do not have a Sonus
Salesforce Customer Portal login account, you can contact the Sonus Technical Assistance Center (TAC).
HP DL380p Gen8 Server is physically commissioned in your network and has access to the network. For
more information, see HP ProLiant DL380p Gen8 Server Quick Start and HP ProLiant DL380p Gen8 Cabling
and Network Connectivity Reference.
Check if you have the terminal access to the HP DL380p Gen8 server.
Must be aware of the EMS account and default passwords. For more information, see Default Account
Names and Passwords.
Must have iLO license key to activate the iLO.
Must have an IP address to configure the iLO.
Super user (root) access on the iLO console.
Need to use either iLO or connect Monitor and Keyboard to the system to install the software.
Must be aware of basic Linux commands.
Must be aware of system BIOS settings to make the system boot from required media.
Must have a basic understanding of initial BIOS sequence/procedure.
Before you install EMS, use the Pre-Installation Checklist to write down your settings.

The checklist consists of a list of planning information you should complete before you start installing EMS.
You can check off each task as you complete it and make notes in the Comments column below. Sonus
recommends that you make note of the parameter values that you need to enter during the installation process and
while configuring EMS.

Table 7: System Information Required for Insight Installation
Parameter Description Example Mandatory? Comments
Primary The Primary Network Interface (PNI) of the system. eth0 Yes
network
interface
name
hostname The name which identifies this system on the network. ems1 Yes
The EMS hostname is limited in length

to 64 characters. The hostname can
only contain lowercase letters [a-z] and
digits [0-9]. The hostname cannot start
with a digit. Special characters including
hyphen are not allowed in hostname.
IP address The Internet Protocol (IP) address for this network 10.9.9.103 Yes
interface.
Default The node on a TCP/IP Network that serves as an access 10.9.9.1 Yes
Router point to another network.
Netmask The mask used to determine to which subnet an IP 255.255.255.0 Yes

of subnet address belongs.
Name The primary DNS server IP address. 10.9.9.97 No

service
(DNS
Server)
Secondary The secondary DNS Server IP address. 10.9.9.98 No

DNS
DNS The domain name to be used for resolving IP address. datacenternoth.com No

Search
Path
The following summary outlines the key steps required to install EMS application on a standalone server.
Before proceeding with the EMS Application installation ensure the steps 1 to 5 to deploy HP ProLiant DL380p
Gen8 server are completed.
Refer the Quick Start Summary section in the HP ProLiant DL380p Gen8 Server Quick Start.
For PDF version, download HP ProLiant DL380p Gen8 Server Quick Start PDF (550-06234).

Download and Prepare the Installation Files
This step identifies the required installation files for download to the HP DL380p Gen8 server and how to prepare
the files for installation.
Install EMS application using iLO remote console.
This step shows you how to install EMS application using the iLO remote console.
Perform Post-installation Tasks on EMS SA.
This step shows the mandatory post-installation steps you need to perform.
Access the EMS GUI.
This step shows you how to access the EMS GUI.
Install EMS License using the License Manager utility in the EMS GUI.
For more information on performing this task, see the Insight EMS User Guide (550-05908).
What To Do Next
For performing some basic EMS housekeeping or configuration tasks on the EMS host, see Common
Administrative Tasks.
Downloading Installation Files
The following two files are required to install EMS application:

Table 8: Files to be downloaded from Salesforce
File Name Downloading Step
ISO Image:
ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso
The software bundles are listed with the product names and software versions.
1. Login to Salesforce customer portal.
2. In the Secure Customer Login, enter your Username and Password.The Sonus Global Support Portal displays.
3. From the SalesForce customer portal, click SOFTWARE DOWNLOADS tab. The Software Downloads screen
displays.
4. Click the software bundle label to view its contents.
5. Click Request Download. The Software Download Form screen displays.
6. Enter the address details and accept the License Agreement.
7. Click Submit. The Submitted request status is displayed.
8. Click SOFTWARE REQUESTS tab. The Software Requests Home screen displays.
9. Click the software request ID associated with the software bundle.
10. Click on the download links from the Software Requests section to download the software.
11. Save the software to your local desktop or server or remote desktop.
There are three options for mounting the ISO image. For more information, see Options for
Mounting ISO Image.
PSX Manager GUI File: Download the PSX Manager GUI TAR file SSGUI_V09.03.00R000_RHEL.tar from the Sonus Salesforce
Customer Portal located in WL9.3 Software Bundle to the local system.
SSGUI_V09.03.00R000_RHEL.tar
HP Firmware File: Downloading the HP firmware file from SalesForce to /opt/sonus/platform directory on server and verify if the
HP firmware version is the latest. For more information about HP firmware latest version and procedure to upgrade
Firmware File the HP firmware, refer the page https://support.sonus.net/display/ALLDOC/HP+DL380p+G8+Firmware+Upgrade.
Installing EMS ISO Image
During EMS SA installation, ignore the following errors, unless DB Instance creation fails. The following
errors are seen on trace/alert log files which is present under: $ORACLE_BASE/admin/SIDB/udump/diag
/rdbms/sidb/$ORACLE_SID/trace
Error Codes:
ORA-00942
ORA-942
1. To start the EMS installation we need to mount the ISO image using iLO of the HP Gen8 server. There are
two methods:
a. Using a Laptop physically connected to the HP Gen8 server through the iLO port
b. Using a PC or Laptop on the same network as the iLO
2.

2. The CD-ROM Installer screen appears.
Figure 2: Installer Screen
3. Type 1 and press ENTER to start the EMS installation using Monitor and Keyboard or Remote Console.
Enter 2 to install Insight Application Server (IAS) and proceed with IAS installation.
The following install status screen appears.

Figure 3: Starting Installation Process
After a few minutes, the following screen appears and you can view the various RPM packages being
installed.
Figure 4: Package Installation

After the packages installation, the post-installation scripts are executed automatically. This process takes 30
minutes approximately.
The following screen appears.
Figure 5: Post-installation screen
4. After successful installation of Red Hat Enterprise Linux, unmount the virtual disk.
5. Unmount the virtual disk as CD ROM by selecting Virtual Drives and clear the Image File check box.

Figure 6: Unmount the Virtual Disk
6. Use the Tab key to select Reboot button. After selecting Reboot button, press Space key to reboot the
system.

Figure 7: Reboot System
7. Press F1 to continue booting the system or it continues by itself after some time.
If you do not press any of the Function keys, by default, the system continues to boot normally.

Figure 8: F1 Key to Continue
8. When the system reboot is complete, the Sonus Network Configuration screen appears. Select Hostname
and press Space key to configure the hostname for the system.
The EMS hostname is limited in length to 64 characters. The hostname can only contain lowercase
letters [a-z] and digits [0-9]. The hostname cannot start with a digit. Special characters including

Figure 9: Sonus Network Configuration
a. In the Host Configuration Screen, specify the Hostname, Primary DNS and DNS Search Path details.
Press Tab key to select OK button and press Space key to save the settings.
The Primary DNS, Secondary DNS, and DSN Search Path configuration parameters are
optional.

Figure 10: Time Zone Selection
b. In the Sonus Network Configuration screen, Select IP Configuration using the Tab key to navigate to
the option and press the Space key to select the option.

Figure 11: Sonus Network Configuration - IP Configuration
c. Select IP4 as IP Format and eth0 as Port. Press the Tab key until OK is selected and then press the
Space key.
Use the Tab key to navigate to the option and press the Space key to select the option.

Figure 12: Network Interface Selection
d. Specify the IP Address, subnet mask, and gateway IP Address for eth0 network interface. Press Tab
key to select OK and press Space key to save the IP Address details.
Figure 13: IP Address Configuration
e. Use the Arrow keys to select Time Zone and press Space key to configure the Time Zone. Select the
nearest Time Zone for the system and press Tab key to select OK and press Space to save the Time

e.
Zone settings.
Figure 14: Timezone
f. After configuring Time Zone, Sonus Network Configuration screen is displayed. Select Time Server
using arrow keys to configure the NTP Time server.
Enter the NTP Time-Server IP Address, to synchronize the time for the host system. Press TAB key
to select OK and press Space to save the configuration.
Figure 15: NTP Server Configuration Screen
9. Select Save&Quit using TAB and press ENTER.

9.
The EMS application installation starts and after completing EMS Installation, login screen is
displayed. The steps 12 to 19 are optional and performed if you want to change the boot priority. If
you do not want to change the boot priority, skip steps 10 to 17 and refer from step 18 onwards.
10. If you want to change the boot setup priority, reboot the system. The The HP BIOS execution screen is
displayed after reboot.
Figure 16: HP ProLiant Screen
11. Press F9 to change the setup.

Set the Boot priority to Hard disk.
The BIOS setup utility screen appears.
ROM based setup is a one time configuration.

Figure 17: ROM Based Setup
12. Select the Standard Boot Order (IPL) option and press ENTER. The boot order appears.
Figure 18: Boot Order
13. Select Hard Drive C: (See Boot Controller Order) and press ENTER.
The choices to change the boot order appears.
Figure 19: Choosing boot order
14. Select the Set the IPL Device Boot Order to 1 option and press ENTER.

14.
The updated boot order appears. The highest priority is changed from USB to Hard Drive.
Figure 20: Updated Boot Order Screen
15. Press ESC.

The BIOS setup utility main menu appears.
16. Press ESC to exit from BIOS setup utility.
The confirmation screen to exit from the BIOS Setup Utility appears.
Figure 21: Configuration Utility
17. Press F10 to save the settings and exit from BIOS setup utility.
The system reboots from the hard disk.
18. The login screen is displayed. Specify the username as root and default password as sonus. After
installing the Linux Operating System, during the first time system reboot, the password must be changed.

Figure 22: Remote Console
19. Enter the new password and press ENTER. The password cannot be same as the login name and must meet
a few restrictions. Following are the restrictions while using strong passwords :
Must be minimum eight characters.
Can be combination of alphabets and numbers, words, numbers or special characters.
The word must not be from dictionary.
Serial letters must be avoided.
Characters must not repeat (word, number, special character).
Must not be reverse of any dictionary word.
Must not be reverse of name.
Figure 23: New Password
20. Enter the password again for confirmation.

21. Execute the following command to verify the EMS Application version:

21.
# rpm -qa SONSems

SONSems-V09.03.00-R000.x86_64
22. Execute the following command to verify the platform version:
# cat /etc/os_version
06.04.02.00R000
Sonus Platform version must be 06.04.02.00R000
23. Execute the following command to verify the platform Kernel version:
# uname -r
2.6.32-504.3.3.el6.x86_64
Kernel release version must be 2.6.32-504.3.3.el6.x86_64

24. Login as oracle user and execute following command to verify Oracle database version:
$ sqlplus -version
SQL*Plus: Release 11.2.0.3.0 Production
Oracle version must be SQL*Plus: Release 11.2.0.3.0 Production.
25. Login as oracle user and execute following command to verify the latest Oracle database patch version:
$ $ORACLE_HOME/OPatch/opatch lsinv | grep 19271438

Patch 19271438 : applied on Sun Feb 01 18:17:30 IST 2015
Oracle patch version must be Patch description: "Database Patch Set Update : 11.2.0.3.0 (19271438)"
After completing the EMS installation, perform the post-installation tasks. For post-installation tasks details,
refer the section Post-Installation Tasks.
<< Back to Top
Performing Post-installation Tasks on EMS SA

This page contains:
Setting the EMS System IP Address and System Password

Installing the PSX Manager GUI on EMS Server
Upgrading iLO Firmware Version
Installing Device Manager (DM)
Checking the Insight Server Status
Starting the Insight Server
This section provides the mandatory post-installation tasks that you need to perform.
Setting the EMS System IP Address and System Password
You can configure the EMS system IP address and passwords using the configureJumpstart.sh script. The
configureJumpstart.sh script changes the server IP address and updates this IP address in the database
tables. Also, this script updates the Netcool license information with the IP address.
By default, after configure jump start we start the insight process. Incase, Firmware upgrade is done and it
involves a reboot of the system, insight process would come up automatically.
For more information about password, see Password Complexity.
The changed password is by default valid for 90 days. If you want to extend the password change duration,
modify the parameter PASS_MAX_DAYS 90 to PASS_MAX_DAYS 99999 in /etc/login.defs file,
using the vi editor.
Perform the following procedure to set the IP address and the system passwords:
1. Log in as root.
2. Enter the following commands:
# cd /opt/sonus/ems/conf
# ./configureJumpstart.sh
3. Enter the EMS IP address of the system, when prompted.
You can use the EMS IP address that you have configured while performing the EMS ISO
installation. Else if you want to change the EMS IP address, you can enter a new IP address.
4. If the following message appears, enter Y if you want to continue and overwrite the existing key.
A key file already exists.

Do you want to continue and overwrite the existing key [y|Y,n|N] ? y
The following messages appear:

Generating a new Key file...
Do you want to upgrade the system passwords to use strong passwords

(production setup) (y|Y) or continue to use the old weak hardcoded passwords
(lab setup) (n|N) (default:Y)?
If you want to use strong passwords (recommended for production setup), enter Y and skip to Step 6.
You can enter new passwords.
If you do not want to use strong passwords, enter N and continue to Step 5. The default passwords
can be used.
5. If you entered N in Step 4, a prompt asks you to confirm that you want to use weak passwords. Enter Y.
When a message appears stating that the script is done, continue to 'Post-Installation Steps'.
When entering strong passwords (Steps 6 through 18), the passwords must meet the restrictions me
ntioned in Password Complexity.
6. If you entered Y in Step 4, a prompt asks for the EMS database (dbimpl) password. Enter the password. (The
only special characters allowed are _ and #).
7. When prompted, re-enter the EMS database password.
8. When prompted, enter the EMS database sys password. (The only special characters allowed are _ and #)
9. When prompted, re-enter the EMS database sys password.
10. When prompted, enter the EMS database system password. (The only special characters allowed are _ and
#)
11. When prompted, re-enter the EMS database system password.
12. When prompted, enter the EMS user password. For high availability and disaster recovery systems, you must
use the same EMS user password on each EMS system.
13. When prompted, re-enter the EMS user password.
14. When prompted, enter the Netcool root database user password.
15. When prompted, re-enter the Netcool root database user password.
16. When prompted, enter the Netcool Insight_Admin_User database user password.
17. When prompted, re-enter the Netcool Insight_Admin_User database user password.
18. When a message appears stating that the script is done, continue to 'Post-Installation Steps'.
Perform the following procedure to install the latest PSX Manager GUI:
1. Login to the EMS server as root user.

2. Perform the following step to verify if the PSX Manager GUI version is the latest:
If the PSX Manager GUI version is not the latest then download the respective release PSX
Manager GUI TAR file (SSGUI_<Version>_RHEL.tar) and execute upgrade steps from Step 3 on
wards.

# rpm -qa | grep SONSpsx
PSX V09.03.00R000
3. Stop EMS by executing the following command as user insight:
# su - insight
$ ./sonusEms stop
4. If the /opt/sonus/install/ directory is not available, create the directory using the following command:
# mkdir -p /opt/sonus/install/
5. Download the SSGUI_V09.03.00R000_RHEL.tar file from Sonus SalesForce Customer portal to local
system.
6. Copy the SSGUI_V09.03.00R000_RHEL.tar file from the local system to the /opt/sonus/install/
directory on the EMS server.
7. Change to the /opt/sonus/install/ directory using the following command:
# cd /opt/sonus/install/
8. Untar the SSGUI_V09.03.00R000_RHEL.tar file using the following command:
# tar -xvf SSGUI_V09.03.00R000_RHEL.tar
9. Change to the /opt/sonus/install/SSGUI directory using the following command:
# cd /opt/sonus/install/SSGUI
10. Execute the GuiClient.sh script as a super root user. The GuiClient.sh script installs the SONSpsx
package at the default installation folder.
# ./GuiClient.sh
If, a prior version of PSX Manager GUI exists a confirmation message to remove the existing version is
displayed. Enter y to uninstall the prior version and install the latest version of PSX Manager GUI.

SONSems-V09.03.00-R000.x86_64
/opt/sonus/ems/weblogic/insight/deploy/insight.ear/emsGui.war/external
SONSpsx-V09.02.00-R000.x86_64
Version V09.02.00 already exists. It must be removed to proceed.

Remove the existing version? (default: N) [y|Y,n|N]: y
The following message is displayed after uninstalling the previous PSX Manager GUI and installing the latest
PSX Manager GUI version.
Removing SONSpsx.
Installing SONSpsx.
Preparing... ########################################### [100%]
1:SONSpsx ########################################### [100%]
11. Verify that the SONSpsx package is installed, by executing the following command:

PSX V09.03.00R000
12. Start EMS by executing the following command as user insight:
# su - insight
$ ./sonusEms start
13. Login to the EMS GUI.

14. Click the Insight Administration icon on the left pane of the EMS GUI.
15. Click the General tab and select PSX Policy Server > PSX Manager Versions on the left bottom pane.
16. Click the Reload button to integrate the new PSX Manager version to Insight EMS server.
17. Access the PSX Manager GUI by clicking on Element Mgmnt > PSX Manager icon on the left pane.
The iLO 4 firmware version running on your EMS system may require an update.
Upgrading iLO Firmware Version only applies to physical host (HP G8) based EMS installations. Upgrading
Firmware is not applicable for EMS SWe installations.
To know the iLO firmware version running on your EMS system and update the iLO firmware to the latest version,
do the following:
1. Login to iLO web interface.

2. Click on Information >System Information on the left pane.
3. Click Firmware tab on the right view pane. Ensure that the iLO version, HP ProLiant System ROM, and HP
Smart Array Controller version matches the latest versions documented in HP DL380p G8 Firmware Upgrade
section in HP ProLiant DL380p Gen8 Server Quick Start.
4.

4. For information on the recommended HP iLO firmware version and how to upgrade to this iLO firmware
version, see HP DL380p G8 Firmware Upgrade section in HP ProLiant DL380p Gen8 Server Quick Start . For
PDF version, download HP ProLiant DL380p Gen8 Server Quick Start PDF (550-06234).
Installing EMS V09.03.00 removes the previous device manager (DM) on the system, if it was installed earlier. After
installing EMS 9.3.0, install the respective DM supported for EMS 9.3.0. For more information on Device Manager,
see the SBC Manager section of the Insight User Guide. For more information on installing or upgrading Device
Manager, refer Installing and Upgrading Device Manager (DM).
To verify the status of the Insight server, login as user insight and execute the following command:
$ ./sonusEms status
To start the Insight server, login as user insight and execute the following command:
$ ./sonusEms start
You can add arguments to the sonusEms start command to control memory size allocations. For a list of the
arguments and their syntax, type:
# ./sonusEms -help
<< Back to Top
The following summary outlines the key steps required to install EMS Standalone application and setup Disaster
Recovery (DR) configuration on the EMS source and target standalone systems.
Before proceeding with the EMS Application installation ensure the steps 1 to 5 to deploy HP ProLiant DL380p
Gen8 server are completed on both the EMS source and target standalone systems.

Download and Prepare the Installation Files on both the EMS source and target standalone systems.
Install EMS application using iLO remote console on both the EMS source and target standalone systems.
Perform Post-installation Tasks on on both the EMS source and target standalone systems.
Configure the two Standalone EMS systems into a DR configuration.
This step shows you how to configure the two Standalone (SA) EMS system located in different geographical
location into a Disaster Recovery (DR) configuration.
What To Do Next
For performing some basic EMS housekeeping or configuration tasks on the EMS host, see Common
Administrative Tasks.
For information on other DR operations, see EMS DR Operations.
Setting Up DR on EMS Standalone systems
This section provides the steps to convert the two separate standalone systems into a DR configuration.
Prerequisites for setting up DR:
Ensure that following prerequisites are met, before setting up DR configuration:
The EMS SA installation should be completed on both the Source and Target systems.
The EMS should be running on the Source and Target systems.
The Target EMS system should be accessible from the Source EMS system, and vice
versa.
To configure the standalone systems as DR setup, perform the following steps:
1. Login as root user into the standalone system which is identified to be the DR Source System and perform
the following step:
# /opt/sonus/ems/conf/DR/manageDR setup
2. A confirmation message to setup DR is displayed. Press y when the following prompt appears:
"Do you want to continue with setting up DR? [y|n]:"
3. Enter the Target EMS system IP address when the following prompt appears:

3.
"Please specify the IPv4 Address of Node 1 of the remote DR TARGET cluster"
The DR Setup configures the source and target EMS systems for replication, backs up the database in the
source system, restores it on the target system, and initiates the replication process.
The DR Setup process takes approximately 30 minutes to complete.
Verifying the DR Configuration
To verify the DR configuration, perform the following step:
1. Login as root user into the DR Source system and execute the following command:
# /opt/sonus/ems/conf/DR/manageDR status
The above command shows the status of DR Setup. For detailed explanation see " Status".
This section provides information on upgrading standalone EMS system and upgrading standalone DR EMS system
on Linux platform.
Rollback EMS SA

In this section:
Upgrading EMS Using ISO Image

INPLACE Upgrade Type
KICKSTART Upgrade Type
EMS Upgrade Configuration File
Editing EMS Upgrade Configuration File
For upgrading from an earlier EMS release to EMS 09.03.00R000, you need to perform the upgrade using the EMS
ISO image. The EMS ISO upgrade method enables you to upgrade the operating system and database apart from
upgrading the EMS application software.
Also, for upgrading from EMS 09.03.00R000 to a post-09.03.00 EMS minor or patch release, use the EMS ISO
upgrade method. For example, for upgrading from EMS V09.03.00 to EMS V09.03.01, use the ISO upgrade method.
Ignore the following errors, unless ORACLE UPGRADE fails. The following errors are seen on trace/alert
log files which is present under:
$ORACLE_BASE/admin/SIDB/udump/diag/rdbms/sidb/$ORACLE_SID/trace
Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700
Table 9: Examples of Upgrade Paths and Supported Upgrade Methods
Upgrading From Release Upgrading To Release Upgrade Method to be Used
V08.04.07 V09.03.00 ISO Upgrade
V09.00.00 V09.03.00 ISO Upgrade
V09.01.00 V09.03.00 ISO Upgrade
V09.01.04 V09.03.00 ISO Upgrade
V09.02.00 V09.03.00 ISO Upgrade
V09.03.00 V09.03.01 ISO Upgrade
ISO image available in the Sonus Salesforce Customer Portal. The EMS ISO image includes Linux Operating
System, EMS application, and EMS database packages. You can download the EMS ISO image to your laptop, or

to a USB or DVD attached to the laptop. The ISO Image enables you to perform upgrade using either INPLACE or
KICKSTART upgrade type.
The ems_upgrade.conf file has a parameter upgradetype. The parameter upgradetype designates
the type of upgrade as INPLACE or KICKSTART. The default value for upgradetype is INPLACE. If you
opt for KICKSTART based upgrade then you need to change the upgradetype parameter to KICKSTART
in the ems_upgrade.conf configuration file.
INPLACE Upgrade Type
INPLACE is the default upgrade type used for upgrading EMS using the EMS ISO Image. The INPLACE upgrade
type enables you to upgrade the EMS software application, operating system, and database to the latest release
versions. The benefit of INPLACE upgrade type is that it upgrades the OS, database and EMS application without
reinstalling them. Sonus recommends the use of INPLACE upgrade type.
KICKSTART Upgrade Type
The KICKSTART upgrade type re-installs OS, database and EMS application. You need to take the backup of the
configuration in a remote location before kickstarting the system. After reinstalling the application, OS, and
database, restore the backup from the remote location to the EMS System.
Upgrade can take longer time if EMS releases (V08.04.07R000 or versions higher) are directly installed or
upgraded to any other release. The upgrade time can be longer depending on the number of rows in
IPTRUNKGROUPINTERVALSTATS table. It is recommended to reorder the columns in this statistics table
in another maintenance window prior to upgrading EMS. For more information, contact Sonus Customer
Support.
EMS Upgrade Configuration File
Before upgrading EMS, you can generate an EMS configuration file ( ems_upgrade.conf). The
ems_upgrade.conf configuration file contains the required EMS upgrade and backup parameters, with the default
values. You can edit the default values in the ems_upgrade.conf file and provide the file as input while
performing the upgrade.
Editing EMS Upgrade Configuration File
Based on your requirements, you can edit the properties defined in the ems_upgrade.conf file using the vi
editor.
The following table provides usage and significance of each property in the ems_upgrade.conf file.

Table 10: Significance of Properties inside ems_upgrade.conf File
Property Name Default Value Usage
_upgrade_type INPLACE Indicates if you want to perform an INPLACE or KICKSTART

Upgrade. It is recommended to use INPLACE upgrade type.
The INPLACE upgrade type performs an upgrade of the
application, OS, and database without need to reimage the
system. While KICKSTART system, reimages the system and
is like a fresh installation. Backup is taken, before performing
a KICKSTART upgrade. If you want to do a KICKSTART upgr
ade, change the _upgrade_type to KICKSTART.
_ems_backup false for INPLACE Indicates whether you want to take the backup of data or not.
For KICKSTART upgrade, the value is true because it
true for KICKSTART reimages the system. For INPLACE upgrade, the default
value is false, however, you can still take the backup, by
changing the value of _ems_backup to true.
_ems_backup_folder /opt/sonus/backup Specifies the directory where the backup must be stored.
This is applicable, if you have specified the value of _ems_b
ackup as true.
_ems_pmstats_table_backup true Indicates, if backup of PM stats tables is required or not.
_ems_pmcsv_backup false Indicates, if PM csv files backup is required.
_ems_sys_conf_backup false for INPLACE Indicates, if backup of system configuration files like IP
configs/contrabs/host files are required or not. The value is
true for KICKSTART true for KICKSTART and false for INPLACE.
_backup_remote_copy false for INPLACE If set to true, backup will be scp-ed to a remote server. The
value is true for KICKSTART and false for INPLACE.
true for KICKSTART
_backup_remote_IP Indicates the IP address of remote server which has a

password-less connection where backup is saved. The
configuration will be read-only if _backup_remote_copy is
true.
_backup_remote_user root Indicates the username of the remote server. Change the
username, based on what is the username set.
_backup_remote_dir /opt/sonus/backup/ Specifies the directory path on the remote server, where
backup is saved. Change the path, based on where you want
to take backup on the remote server.
Before you upgrade EMS, review the following prerequisites:
Upgrade operation is not supported with the changed netcool object server name. To perform an upgrade,
you need to first rollback to default netcool object server name “SONUSDB”. For changing the netcool object
server name, refer Changing Netcool DB Object Server Name for EMS SA.
Backup data and copy it to a remote system, before performing an EMS SA Upgrade. System backup is
critical and can be used, if EMS upgrade fails. For more information on how to backup, refer the section
System backup.

Check if you have the terminal access to the EMS server.
Must be aware of the EMS account and default passwords.
Super user (root) access on the EMS server.
System Backup
Before upgrading EMS SA, backup EMS data and copy it to remote server. Backup of data is needed in case if EMS
upgrade fails.
Perform the following steps to back up the system:
1. Log on to the EMS system as a user with root privileges.

2. Run the manualBackup.sh script using the following commands on the active system:
# ./manualBackup.sh <yourbackupdirectory>
where <yourbackupdirectory> should be replaced with the actual path for the directory in which you wish
to store your backup files. Use a directory that is external to the EMS machine. Use a directory name that will
clearly identify the EMS server that created the backup files. Make a note of the directory path because you
will need it later if you need to restore the system. The script returns the following text:
Creating backupFiles.tar.
Running Oracle export script from Oracle account.
Moving the files to <yourbackupdirectory>.
Backup procedure completed successfully.
The backup results in the creation of backupFiles.tar anddmp files in the backup directory. Copy the
backup files to a remote server, which enables restore of data later in case if EMS upgrade fails.

This section contains the following topics:
Files to be Downloaded
Downloading the EMS Software Bundle
PSX Manager GUI File
Firmware Upgrade
The following table provides list of files to be downloaded for ISO upgrade.

Table 11: List of Files to be Downloaded
ISO Upgrade Files
ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso
upgradeEMS.sh
Firmware file

To avoid shortage of disk space, remove previous release directories created in the path /opt/emsInstal
l/. For example, while upgrading to Release V09.02.00, you might have created new directory 9.2 in the
path /opt/emsInstall/. To reclaim space occupied by previous-release folders under /opt/emsInsta
ll/, you can remove the previous release directories, using the following command:
# rm -rf /opt/emsInstall/<Previous-Release-Directory>
For Example:
# rm -rf /opt/emsInstall/9.2
The EMS software bundle is available as a software package downloadable from the Salesforce customer portal.
1. Login to Salesforce customer portal using your Sonus provided login, and click SOFTWARE DOWNLOADS.
2. Click software bundle WL9.3 to view its contents, and then click Request Download.
3. Fill in the Software Download Form, accept the license agreement and click Submit.
4. When the "Request Status" on the SOFTWARE REQUESTS page displays "Download Available", click the
links in the WL9.3 software bundle.
Usage Download Procedure

The ISO file Perform the following steps to download ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso and upgradeEMS
ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso .sh files:
contains the EMS 9.3.0 application, OS, and database
updates. This ISO file is used for both INPLACE and
Enter the <NEW_EMS_VERSION> directory name as the EMS release number to which you
KICKSTART upgrade types.
are upgrading. For example, to upgrade to 9.3 release, instead of <NEW_EMS_VERSION> spe
The upgradeEMS.sh file is a script which is required to
cify 9.3 as directory name. The directory <NEW_EMS_VERSION> where you are downloading
perform ISO upgrade. The upgradeEMS.sh file performs
the file, must be empty and must not contain other files. Ensure that the directory allows any
all the necessary tasks such as system checks, create
user to read and execute the files and has enough space for extracting Insight upgrade files.
backup of configuration, upgrade OS, Database and
EMS Application.
1. Login to the shell on EMS server as root user.

2. Create a fresh directory by using the following command:
# mkdir -p /opt/emsInstall/<NEW_EMS_VERSION>/
3. Download the ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso and upgradeEMS.sh files from the Sonus

Salesforce Customer Portal to /opt/emsInstall/<NEW_EMS_VERSION>/ directory.
4. Change to the following directory:
# cd /opt/emsInstall/<NEW_EMS_VERSION>/
5. Change the execute permission of upgradeEMS.sh using the following command:
# chmod +x upgradeEMS.sh
Download the PSX Manager GUI TAR file SSGUI_V09.03.00R000_RHEL.tar from the Sonus Salesforce
Firmware Upgrade
If you are upgrading EMS SWe for KVM or VMware ESXi, upgrading iLO is not required. Upgrading iLO
firmware is applicable only for EMS physical server-based upgrade.
Downloading the HP firmware file and verify if the HP firmware version is the latest. For more information
about HP firmware latest version and procedure to upgrade the HP firmware, refer the page https://support.
sonus.net/display/ALLDOC/HP+DL380p+G8+Firmware+Upgrade.
This is the HP G8 DL380 firmware upgrade file. Ensure that the HP DL380 G8 firmware is upgraded after you perform the EMS Download the firmware file from Salesforce
Software upgrade using the ISO file. Customer Portal to:
/opt/sonus/platform directory in the server.

The following summary outlines the key steps required to upgrade EMS standalone server using ISO INPLACE
upgrade.

Download and prepare the upgrade files.
This step identifies the required upgrade files for download to the HP DL380p Gen8 server and how to prepare
the files for upgrade.
Backup the EMS by splitting the disk mirror.
This step stops the disk mirroring, ensuring that the secondary disks retain the older EMS data.
Sonus recommends to manually backup data to a remote server, before performing an

upgrade.
Perform the INPLACE upgrade procedure.
This step performs an INPLACE upgrade of EMS.
Perform the mandatory post-upgrade tasks.
This step performs the post-upgrade tasks.
Re-Mirror the disks.
This step re-mirrors the disks. Perform this step, if the EMS upgrade is successful.
If the upgrade is not successful, then you can revert back to the previous EMS release. For more
information, see Reverting Back To Previous EMS Release.
INPLACE Upgrade Procedure
log files which is present under: $ORACLE_BASE/admin/SIDB/udump/diag/rdbms/sidb/$ORACLE_S
ID/trace
Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700
The total time taken for upgrading and total service downtime of the EMS Standalone server during the ISO
INPLACE upgrade is 35 to 40 minutes approximately.
You can perform an ISO upgrade using either INPLACE or KICKSTART upgrade type. By default, the
upgradetype parameter in ems_upgrade.conf configuration file is set to INPLACE. It is recommended to use
INPLACE upgrade. The INPLACE upgrades preserves all system settings, services or custom configurations of the
operating system.

Before performing the upgrade, you need to take a backup of /etc/ntp.conf and /etc/issue files.
You can restore these files after the EMS upgrade is complete.
To upgrade the EMS Standalone system using INPLACE upgrade, perform the following steps:
1. Log in as root to the EMS server.

2. Verify if the ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso and upgradeEMS.sh files
are downloaded and available at /opt/emsInstall/<NEW_EMS_VERSION>/
3. Change directory to /opt/emsInstall/<NEW_EMS_VERSION>/.
The <NEW_EMS_VERSION> is the directory, created while downloading the upgrade files. For
example, if you have created a directory /opt/emsInstall/9.3 for upgrading to 9.3, change the
directory to /opt/emsInstall/9.3.x/ (replace <NEW_EMS_VERSION>) with 9.3 in the following
command:
4. Change the permission of the upgradeEMS.sh file using the following command:
5. INPLACE upgrade can be done using the default settings or by configuring the ems_upgrade.conf file.
Table 12: Selecting Upgrade Option
Upgrade Option Perform
Default Upgrade Step 6
Upgrade using Configuration File (ems_upgrade.conf) Step 7
6. Execute the following command to upgrade EMS using default settings:
# ./upgradeEMS.sh -p
/opt/emsInstall/<NEW_EMS_VERSION>/ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso
Skip step 7, and continue with step 8.
7. To change the default EMS upgrade and backup configuration, perform the following:
a. Execute the following command to generate the ems_upgrade.conf file:

# ./upgradeEMS.sh -g [Absolute Path of ems_upgrade.conf configuration
file]
For example, if you want to generate the ems_upgrade.conf file in the

/opt/emsInstall/<NEW_EMS_VERSION> directory then execute the following command:
# ./upgradeEMS.sh -g /opt/emsInstall/<NEW_EMS_VERSION/ems_upgrade.conf
b. Once the configuration file is generated, you can edit the parameters in the ems_upgrade.conf file
using the vi editor. The ems_upgrade.conf file contains comments that guides you in editing the
upgrade/backup parameter values.
# vi ems_upgrade.conf
# Configuration template for EMS upgrade

# You may edit this file before the EMS Upgrade
#
# Allowed values for "_upgrade_type" are INPLACE or KICKSTART ; change it
to KICKSTART if you want to perform a kickstart-based upgrade.
_upgrade_type=INPLACE
# By default, the value for "_ems_backup" is "false" in case of

INPLACE-upgrade and "true" in case of KICKSTART-upgrade. Change it to
true/false to override the default value.
# It is HIGHLY RECOMMENDED to take the backup, so that it can be used to

restore the previous EMS if anything goes wrong. Also, the configurations :
_ems_pmstats_table_backup,_ems_pmcsv_backup,_ems_sys_conf_backup,_backup_remote_copy
are not read, if "_ems_backup" is set to "false".
_ems_backup=
# Directory, where the EMS backup should be kept. Please modify, if

required.
_ems_backup_folder=/opt/sonus/backup
# Change the value to "false", if PM stats tables backup is not required.

_ems_pmstats_table_backup=true
# Change it to true if PM csv files backup is required.

_ems_pmcsv_backup=false
# By default, the value is set to "true" for KICKSTART-upgrade and "false"

for INPLACE-upgrade.
# Change the value to "false", if the backup of System Configuration files
like IP configs/crontabs/host files etc. are not required.
_ems_sys_conf_backup=

# If the value is set to "true", then the data backup will be scp-ed to a
remote server.
for INPLACE-upgrade.Change it to true/false to override the default value.
_backup_remote_copy=
# Remote Server Details : The following are to be given only if this server
has a password-less connection to the remote server where you want the
backup to be copied. This configuration will be read, only if
_backup_remote_copy is "true".
# Please enter the remote server's IP.
_backup_remote_IP=
# Username of the remote server. Please modify, if required.

_backup_remote_user=root
# Backup directory in the remote server. Please modify, if required.

# Please note that, this directory should exist in the remote server.
_backup_remote_dir=/opt/sonus/backup
Save the ems_upgrade.conf file, after changing the parameter values.

c. After you have generated and updated the ems_upgrade.conf file, execute the following command:
# ./upgradeEMS.sh -c [Absolute Path of ems_upgrade.conf configuration

file] -p
8. The system gets rebooted if there is an OS upgrade involved. The upgrade will continue after the system
starts.
After the system is up, execute the following command to see the upgrade progress:
# tail -f /var/sadm/install/logs/upgradeEMS.log
# rpm -qa SONSems

SONSems-V09.03.00-R000.x86_64
10. Perform the following steps to verify if EMS, database and kernel have been updated:
a. Execute the following command to verify the platform version:
06.04.02.00R000
b. Execute the following command to verify the platform Kernel version:
# uname -r
2.6.32-504.3.3.el6.x86_64
c. Login as oracle user and execute following command to verify Oracle database version:
$ sqlplus -version

d. Login as oracle user and execute following command to verify the latest Oracle database patch
version:
Oracle patch version must be Patch description: "Database Patch Set Update : 11.2.0.3.0
(19271438)"
After completing the EMS upgrade, perform the post-upgrade tasks. For post-upgrade tasks
details, refer the section Post-Upgrade Tasks.

The following summary outlines the key steps required to upgrade EMS application on a standalone server using
ISO KICKSTART upgrade.
This step identifies the required upgrade files for download to the HP DL380p Gen8 server and how to prepare
Backup the EMS by splitting the disk mirror.
Sonus recommends to manually backup data to a remote server, before performing an

upgrade.
Perform the KICKSTART upgrade procedure.
This step performs a kickstart upgrade of EMS.
Re-Mirror the disks.
If the kickstart upgrade is not successful, then you can revert back to the previous EMS release. For more
KICKSTART Upgrade Procedure

You can perform an ISO upgrade using INPLACE or KICKSTART upgrade type. By default, the upgradetype
parameter in the ems_upgrade.conf file is set to INPLACE. It is recommended to use INPLACE upgrade. In case,
you want to perform the KICKSTART upgrade then you need to change the value of upgradetype parameter to
KICKSTART in the ems_upgrade.conf file.
The KICKSTART upgrade type re-installs OS, database and EMS application. You need to take the backup
of the configuration in a remote location before kickstarting the system. After reinstalling the application, OS,
and database, restore the backup from the remote location to the EMS System.
To upgrade the EMS Standalone system using KICKSTART upgrade, perform the following steps:
ID/trace
Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700

2. Verify that the ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso and upgradeEMS.sh
files are downloaded and available at the /opt/emsInstall/<NEW_EMS_VERSION>/ directory.
Change directory to /opt/emsInstall/<NEW_EMS_VERSION>/ .
The <NEW_EMS_VERSION> is the directory created while downloading the upgrade files. For
directory to /opt/emsInstall/9.3/ (replace <NEW_EMS_VERSION>) with 9.3 in the following
command:
4. Generate the ems_upgrade.conf file and change the _upgrade_type parameter value to KICKSTART.
a. Execute the following command to generate the ems_upgrade.conf file.

file]
For example, if you want to generate the ems_upgrade.conf file in the /opt/emsInstall/
<NEW_EMS_VERSION>/ directory then execute the following command. Executing the following
command, generates the ems_upgrade.conf file at the specified path.
# ./upgradeEMS.sh -g /opt/emsInstall/<NEW_EMS_VERSION>/ems_upgrade.conf
b. Once the configuration file is generated, change the _upgrade_type parameter value to
KICKSTART in the ems_upgrade.conf file. The ems_upgrade.conf file contains comments that
guides you in editing the upgrade/backup parameter values.

#
_upgrade_type=KICKSTART


_ems_backup=

required.




remote server.
_backup_remote_IP=


Save the ems_upgrade.conf file, after performing the changes.
5. Take the backup the EMS configuration to a remote machine using the following command:
Please make sure that in the BIOS boot order hard disk has given the highest preference so that if
reboots are involved during the upgrade then it automatically boots to hard disk.
# ./upgradeEMS.sh -c [Absolute Path of ems_upgrade.conf configuration file] -p

6. When the script prompts you to specify the location to store the EMS configuration backup files, enter the
remote machine details.
7. After the backup is generated and stored on the remote machine, kickstart the system. Kickstarting the
system, performs an installation of OS, database, and EMS Software Application V09.03.00. For more details
on kickstarting the system, see Installing EMS ISO Image.
Check for the availability of these files in the remote system before kick starting the box: <hostnam
e>.emsConfig.tar and <hostname>.backupData.tar
8. After the system is kick-started, verify if the EMS upgrade is successful using the following command:
# rpm -qa SONSems

SONSems-V09.03.00-R000.x86_64
9. Change directory to /opt/sonus/ems/conf using the following command:
10. Restore the backup from the remote machine to the EMS server using the following command:
# ./upgradeEMS.sh -r
11. The script prompts you to specify the location EMS configuration backup files, enter remote machine details.
To check the upgrade progress, go to the /var/sadm/install/logs/ directory and view the
latest log files to ensure upgrade is successful.
The above procedure completes the upgrade process for EMS Standalone using ISO KICKSTART upgrade.

12.
a.
06.04.02.00R000
# uname -r
2.6.32-504.3.3.el6.x86_64
$ sqlplus -version

version:
(19271438)"
If the kickstart upgrade is not successful, then you can revert back to the previous EMS release. For more
<< Back to Top

The following summary outlines the key steps required to upgrading EMS application for EMS standalone DR
configuration.

ID/trace
Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700
Download and prepare the upgrade files on the source and target EMS standalone systems.
This step identifies the required upgrade files to be download to the HP DL380p Gen8 servers and how to prepare
Backup the EMS by splitting the disk mirror on the source and target EMS standalone system.
a. Perform KICKSTART upgrade procedure or INPLACE upgrade procedure on the

source EMS system.
b. Perform KICKSTART upgrade procedure or INPLACE upgrade procedure on the target
EMS system.
Ensure that the upgrade of the Target EMS site is started within about 15 minutes of starting
the upgrade of the Source EMS site. In other words, if upgradeEMS.sh is called on the
Source EMS site for example around 10:00 AM, then the upgradeEMS.sh on the Target
EMS site should be called no later than about 10:15 AM.
This restriction is required so that the upgrade script can automatically setup the DR
relationship on the upgraded EMS sites at the end of upgrade process.
DR is automatically torn down before upgrade and then automatically setup after upgrade.
Perform the mandatory post-upgrade tasks on the source and target EMS standalone system.
Re-Mirror the disks on the source and target EMS standalone system.
The EMS Disaster Recovery (DR) is setup automatically after successful upgrade of source and target
systems. For information on other DR operations, see EMS DR Operations. To verify that DR connectivity
has been setup after upgrade, execute the command manageDR status on the source DR site.

This section provides the mandatory post-upgrade tasks that you need to perform.
Installing the PSX Manager GUI

wards.

PSX V09.03.00R000
# su - insight
$ ./sonusEms stop
system.

10.
# ./GuiClient.sh
SONSems-V09.03.00-R000.x86_64
SONSpsx-V09.02.00-R000.x86_64

Removing SONSpsx.
Installing SONSpsx.
Preparing... ########################################### [100%]
1:SONSpsx ########################################### [100%]

PSX V09.03.00R000
# su - insight
$ ./sonusEms start


do the following:

Upgrading Device Manager
Upgrading EMS to V09.03.00 removes the previous device manager (DM) on the system, if it was installed earlier.
After upgrading EMS 9.3.0, install the respective DM supported for EMS 9.3.0. For more information on Device
Manager, see the SBC Manager section of the Insight User Guide. For more information on installing or upgrading
Device Manager, refer Installing and Upgrading Device Manager (DM).
For information on additional post-installation tasks (non-mandatory), see Performing Post-Installation or

Upgrade Tasks.
Rollback EMS SA
Rollback Options
Following are the rollback options to revert back to the previous EMS:
Table 13: Rollback Options
Rollback Pre-requisite Revert Procedure

Using
Disk Backup the EMS by splitting the disk mirror. Reverting Back To Previous EMS
Mirroring Release
Manual Manually backup data before upgrade and move it to remote server Reverting EMS to Previous Version
Backup For more details, refer System backup by restoring backup
Reverting the EMS SA to previous version
If EMS upgrade is not successful or if EMS is not stable after an upgrade then perform the following steps:
1. Install Insight EMS using the old ISO by performing the following:
For EMA SA deployed for DR setup, perform the following steps on source and target DR sites.
a. Perform Insight Installation using the old ISO. see "Installing EMS ISO Image".
b. Perform "Post-Installation Steps".
c. Enter the following command to start Insight as user insight:

$ ./sonusEms start
2. Log in as root. Copy the following files from the backup directory on the remote server to the current location
(For example, /export/home/backups):
Table 14: Restoring Backup Files
The file expdp_stats_data_manual.dmp will be generated only if the PM stats export option is enabled.
When Backup is generated from Backup Files generated are
Pre-9.2.0 Release backupFiles.tar
exp_data_manual.dmp
exp_strct_manual.dmp
9.2.0 Release backupFiles.tar
expdp_data_manual.dmp
expdp_strct_manual.dmp
9.2.1 and above Releases (including 9.3.x Releases) backupFiles.tar
expdp_cfg_data_manual.dmp
expdp_stats_data_manual.dmp
3. Run the following command as root user:
# cd /export/home/pkg
4. Enter the following command to migrate the data:
# ./EMSmigration -b /export/home/backups
OR Replace the directory /export/home/backups with the directory that you are using for your backup
data. The following output appears:

Starting EMS migration on emshp1 ........................................ (ok)
Performing EMS data migration on local EMS node. Please wait ............ (ok)
Starting installation on non-primary nodes .............................. (ok)
Performing remote EMS data migration on emshp2. Please wait ............. (ok)
Starting Insight EMS server. Please wait ................................ (ok)
Completed EMS migration on emshp1 ....................................... (ok)
The logs for the migration procedure is available at /var/sadm/install/logs/EMSmigration*.

log
For EMS SA deployed for DR setup, after rollback of previous data is completed on source and
target DR sites, setup DR by executing the command ./manageDR setup on the EMS system at
the source DR site. For more information, refer Setup.
This section provides information on migrating the EMS standalone system from Solaris to Linux platform.

The following summary outlines the key steps required to migrate EMS standalone system from Solaris (Sun Netra
240 or 440 or T5220) to Linux (HP DL380p G8) platform.
Ensure that the EMS Solaris standalone system (Sun Netra 220 or 440 or T5220) is up and running.
Download the migrationExport.sh script and EmsSolarisMigration.tar file from the Sonus
Salesforce portal.
Login as root to the EMS Solaris system and copy the migrationExport.sh script and EmsSolarisMigr
ation.tar file to the system.

Change the file permission of migrationExport.sh to make the script executable using the following
command:
# chmod +x migrationExport.sh
Export Data from the EMS Standalone Solaris System.
Import Data to the EMS Standalone Linux System.
Perform the Post-Migration Procedures.
Exporting Data from EMS Standalone Solaris System
Overview
If your current EMS application and data is installed on a Solaris OS with Netra 240/440 system and if you are want
to migrate to a Linux OS on a HPG8 system then you need to perform the following task on the Solaris Netra
240/440 system. From EMS Software Release V09.02.00 onwards, following tasks are simplified and automatically
performed by executing the ./migrationExport.sh script.
Netcool Installation
Exporting Netcool Data
Database (DB) backup
In EMS Software Releases prior to V09.02.00, the above tasks were performed separately. From EMS
Software Release V09.02.00 onwards, all the three tasks are done automatically.
The migration files generated when migrating from Solaris to Linux are:

Table 15: Migration Files
When Migrating to Migration Files generated are
NetcoolBackupFiles.tar
Prerequisites
The prerequisites to export data from Solaris system, are as follows:
The Solaris Netra 240/440 system must be up and running.

Download the migrationExport.sh script and EmsSolarisMigration.tar file from Salesforce.
Copy the migrationExport.sh script and EmsSolarisMigration.tar to the EMS system where you
want to take backup.
After downloading the file migrationExport.sh, login as ‘root’ user and change the permission of
migrationExport.sh using the following command:
Procedure
Perform the following procedure to perform OMNIBus Installation and export data from the Solaris system:
1. Login as root user on Solaris machine.
Ensure that permission for migrationExport.sh has been changed as root user, using the ch
mod +x migrationExport.sh command. The permissions must be changed before the following
step is executed.
2. Ensure that you are in the directory where you want to perform backup. Both the files
./migrationExport.sh script and EmsSolarisMigration.tar are available in this directory. Execute
the following command to install OMNIBus and export data from Solaris to Linux system.

# ./migrationExport.sh -p EmsSolarisMigration.tar
This script does the following:
-->Netcool OMNIBus 7.3.1 Installation

-->Netcool OMNIBus 7.3.1 Fix 1 Installation
-->Exporting NetcoolData
-->DB Backup
Do you want to continue?(default: n) [y|n]: y
Extracting EmsSolarisMigration.tar . . .
Checking for availability of the files required for performing migration . . .
Check completed.
. . . . .
Netcool OMNIBus 7.3.1 has been installed successfully !!
Extracting 7.3.1-TIV-NCOMNIbus-solaris2-FP0001.tar . . .
Please tail /var/ems/migrateExport.log to track progress.
Installing Netcool OMNIBus 7.3.1 Fix 1 . . .
Netcool OMNIBus 7.3.1 Fix 1 has been installed successfully !!
. . . . .
. . . . .
. . . . .
Export: Release 11.2.0.3.0 - Production on Fri Apr 11 04:03:05 2014
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 -
64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Export done in UTF8 character set and AL16UTF16 NCHAR character set
Note: grants on tables/views/sequences/roles will not be exported
Note: indexes on tables will not be exported
Note: constraints on tables will not be exported
. exporting pre-schema procedural objects and actions
. exporting foreign function library names for user DBIMPL
. . . .
. . . .
DB BackUp successfully completed !
The Backup files are available in /export/home/backup.
/var/ems/migrateExport.log has been included in the backupFiles.tar tar for
future reference.
The above procedure completes Netcool installation, exporting netcool data, and database (DB) backup.
Importing Data to EMS Standalone Linux System
Importing Data
Perform the following procedure to import the previously backed up database and Netcool data onto an EMS Linux
SA system.
1. Log on to the Linux system as root.

2. From the backup directory you used for the existing Netra 240/440 or T5220 server, copy the dmp files to the
/opt/oracle/backup/dump directory. Also, copy the backupFiles.tar and
NetcoolBackupFiles.tar to the /tmp directory.
If the dmp files are copied to <ORACLE_BASE>/backup/dump using an unconventional method, such as
FTP, change the owner and group of the files to Oracle and DBA.

If the dmp files are copied to /export/home/backups using an unconventional method, such as
FTP, change the owner and group of the files to Oracle and DBA.
If migrating to 9.2.1 and above (including 9.3.0) then use the following dmp file names:
# cd /opt/oracle/backup/dump
# chown oracle:dba expdp_cfg_data_manual.dmp
expdp_stats_data_manual.dmp expdp_strct_manual.dmp
or
If migrating to 9.2.0 then use the following dmp file names:
# chown oracle:dba expdp_data_manual.dmp
3. Enter the following:
If Proxy Preferred IP address is configured in old EMS Solaris and if it is different from EMS IP
address, then you will be prompted to enter a new value for the Proxy Preferred IP address while
migrating to EMS Linux
# cd /opt/sonus/ems/conf/jumpstart
# ./emsMigrate.sh -m
4. The system displays the following:
Do you wish to continue [y|Y,n|N] ? y
Type y and press ENTER.
Enter directory for backupFiles.tar,NetcoolBackupFiles.tar:
Enter /tmp and press ENTER.

Do you wish to import User Activity Logs, PM Stats and TrunkGroup Tables
[y|Y,n|N] ?
Type y to restore the data (User Activity Logs, PM Stats and TrunkGroup Tables) or type n if you do not want
to restore the data and press ENTER.
7. The system displays the following after few minutes (Approximately 20 minute):
The Sonus Insight migration is complete.
8. Enter the following command to start Insight as user insight:
$ /opt/sonus/ems/sonusEms start
Reboot the system if the following error appears when you start Insight server after migration:
Failed to connect Error: Failed to get login token
Performing Post-Migration Procedures

This section covers the following topics:
Associating the Device Nodes to the EMS Standalone Linux System

Disassociating the Device Nodes from the EMS Standalone Solaris System
(Optional) Discovering SGX-4000 Device
This section provides information on the post-migration procedures that you need to perform the EMS standalone
Linux system.
Associating the Device Nodes to the EMS Standalone Linux System
Perform the following procedure to associate the nodes to the current EMS Linux Standalone system IP address:
1. Select the Managed Device Association link.

2. Enter the EMS Linux SA IP in the IP Address field as shown below.

Figure 24: Associate IP Address field
3. Click the Associate button.

Figure 25: Associate IP address field confirmation screen
4. Click OK.
The operation may take a longer time depending on the number of nodes. If there are any errors displayed on
the final screen at the end of the operation, then the nodes were not successfully discovered. You need to
perform a manual discovery of the nodes after determining the cause of the error. For more details, refer to
the Node discovery section of the Insight User Guide.
Disassociating the Device Nodes from the EMS Standalone Solaris System

Disassociate all of the nodes with the old EMS IP address to avoid traps being sent from the nodes to the old EMS
IP address. Perform the following steps to disassociate all of the nodes:
1. Navigate to the Insight Administration screen, and click the General tab.
3. Enter the old EMS IP in the IP Address field as shown below.
Figure 26: Disassociate IP Address field
4. Click the Disassociate button.

The following screen appears:
Figure 27: Disassociate IP Address confirmation screen
5. Click OK.
The operation may take a longer time to complete depending on the number of nodes.

5.
If there are any errors displayed on the final screen at the end of the operation, then the nodes were not
successfully disassociated. You need to perform a manual configuration to remove the old IP address as the
trap destination.
After migrating data from one EMS server (A) to another EMS server (B), and after registering
Insight node B, you need to unregister Insight node A (which will show up registered as a result of
the migration)
(Optional) Discovering SGX-4000 Device
If SGX4000 device is configured on pre-V09.01.00 Insight system, you have to perform the following procedure
during data migration from any pre-V09.01.00 Insight system to Insight V09.01.00.
1. Login to Insight.
2. Navigate to Network Mgmt > Insight Administration.
3. Select the registered SGX4000 node from the Navigation tree.
4. Modify and Update the following (default) values if required:
a. -SSH Port
b. -Login (CLI)
c. -Password (CLI)
d. Click on Update button and then click on Discover node.

The following summary outlines the key steps required to migrate EMS standalone DR systems from Solaris (Sun
Netra 240 or 440 or T5220) to Linux (HP DL380p G8) platform.
Teardown the DR setup on the EMS systems.
Ensure that the source and target EMS Solaris standalone systems (Sun Netra 220 or 440 or T5220) are up
and running.
Download the migrationExport.sh script and EmsSolarisMigration.tar file from the Sonus
Salesforce portal.
Login as root to the EMS Solaris systems and copy the migrationExport.sh script and EmsSolarisMig
ration.tar file to the systems.
Change the file permission of migrationExport.sh to make the script executable using the following
command on source and target systems:

Export Data from the source EMS DR Solaris System.
Import Data to the source and target EMS Standalone DR Linux Systems.
Perform the Post-Migration Procedures on the source and target systems.
Setup DR on the EMS source standalone system.

This section provides information on installing and upgrading EMS HA system on Linux platform.
Introduction
The EMS HA deployment consists of two EMS systems, configured to work as a high-availability setup. The benefit
of an EMS HA Deployment is, even when the Primary EMS server goes down, the Secondary EMS Server can
assume the role of Primary and continue providing the services without little or no downtime.
You may require a high availability provisioning infrastructure that is resilient to system failures. Sonus provides
such an infrastructure based on the EMS High Availability (HA) feature. The EMS HA feature is implemented
through the use of a pair of collocated HP DL380p G8 hardware platforms with a common IBM DS3524 RAID disk
array or IBM Storwize V3700 virtualizing RAID Storage system to store the EMS database, the Netcool DB, and
other reports. This architecture of Active system, Standby system, and RAID disk array is conceptually one logical
EMS. If the Active system fails, the Standby system automatically takes over with no manual intervention required.
The two systems which comprise the EMS have redundant LAN links between them that are used for inter-system
Keep-Alive communication and monitoring.
The Failover Process
The failover process occurs as follows:
1. A failure in process, connectivity, or resource is detected.

2. The processes which must only run on the active EMS system are shut down
3. The active EMS unmounts the shared RAID array.
4. The shared logical IP address is removed from the active EMS and started on the standby EMS.
5. The standby EMS mounts the shared RAID array.
6. The standby EMS starts the processes that only run on the active.
The entire failover process takes less than a minute to complete.
Table of Contents


Post-Upgrade Steps
Rollback EMS HA

Migrating Data from Sun Solaris with StorageTek RAID or IBM DS3524 to HP G8 on Linux with
IBM V3700 RAID
This section provides information on installing EMS HA system on Linux platform. This section also provides
information on configuring DR for EMS HA.
Before you install the EMS software, review the following prerequisites:
Download the latest EMS Documentation from

https://support.sonus.net/display/ALLDOC/Insight+EMS+Documentation.

HP DL380p Gen8 Server is physically commissioned in your network and has access to the network. For
more information, see HP ProLiant DL380p Gen8 Server Quick Start and HP ProLiant DL380p Gen8 Cabling
and Network Connectivity Reference.
Check if you have the terminal access to the HP DL380p Gen8 server.
Must be aware of the EMS account and default passwords.
Must have iLO license key to activate the iLO.
Must have an IP address to configure the iLO.
Super user (root) access on the iLO console.
Need to use either iLO or connect Monitor and Keyboard to the system to install the software.
Must be aware of basic Linux commands.
Must have a basic understanding of initial BIOS sequence/procedure.
Before you execute the ./EMSRACinstall script, ensure that ClusterName-Scan and the three scan
IP-address entries are added into the domain-name in DNS.
When you try to resolve the ClusterName-Scan, the Scan IPs must be resolved. As shown in the following
example:
# nslookup Prim1Sec2-scan
Server: 10.34.13.200
Address: 10.34.13.200#53
Name: Prim1Sec2-scan.datacenterlab.com
Address: 10.56.166.5
Address: 10.56.166.6
Address: 10.56.166.7
The host names of the EMS HA nodes should be distinct. Name of one node should not be a part of the
name of the other node. For example, do not name the nodes as 'ems' and 'ems2' (as first node name is a
subset of the name of second node). Instead, provide the hostname with first three letters indicating the
location (Westford), the next three letters indicating the product (EMS) and its identification number. a and b
denotes the system host name and its peer. For example, wfdems01a and wfdems01b.
Adding IPv6 support on EMS HA is only supported during installation.
Before you install EMS, use the Pre-Installation Checklist to write down your settings.

The checklist consists of a list of planning information you should complete before you start installing EMS in high
availability configuration.
You can check off each task as you complete it and make notes in the Comments column below. Sonus
recommends that you make note of the parameter values that you need to enter during the installation process and
while configuring EMS.
All Public IP addresses except DNS IP and iLO IP should be configured in same subnet.
The configuration parameter examples depicted below are from the Sonus Test Lab environment and do
not portray the examples of a production environment.
Table 16: System Information required for Insight HA Installation
Parameter Value for your system Examples Mandatory? Comments

(fill in)
Cluster Config
Cluster The name of the cluster. emsha1 Yes

Name
The cluster name must be at

least one character long and no
more than 15 characters in
length, must be alphanumeric,
and may contain hyphens
The name of the cluster can only contain

lowercase letters [a-z], digits [0-9], and
hyphen[-].
The cluster name cannot start with a digit or

hyphen, and cannot end with a hyphen.
Cluster VIP A virtual IP address used to uniquely connect to 10.54.159.2 Yes

the EMS (owned by whichever server is active).
IPv6 Cluster A virtual IPv6 address used to uniquely connect fd00:10:6b50:4020::56/60 No

VIP to the EMS (owned by whichever server is
(optional) active).
Gateway The IP address of the gateway 10.54.159.1 Yes
Netmask of The mask used to determine to which subnet an 255.255.255.0 Yes

subnet IP address belongs.

Name The primary DNS server IP address. 10.54.163.1 Yes
Service
(DNS
Server)
Secondary The secondary DNS Server IP address. 10.54.163.2 No

DNS
DNS Search The domain name to be used for resolving IP datacenternorth.com Yes
Path address.
NTP Server The Network Time Protocol server 10.128.254.68 Yes
SCAN The first IP address used by the Oracle SCAN 10.54.159.200 Yes
Listener IP (single client access name) listener.
Address 1
SCAN The second IP address used by the Oracle 10.54.159.201 Yes

Listener IP SCAN (single client access name) listener.
Address 2
SCAN The third IP address used by the Oracle SCAN 10.54.159.202 Yes
Listener IP (single client access name) listener.
Address 3
Node 1 (Primary Server)
Hostname The name which identifies this system on the wfdems01a Yes
network.
The EMS hostname is limited in

length to 64 characters. The
hostname can only contain
lowercase letters [a-z] and digits
[0-9]. The hostname cannot start
with a digit. Special characters
including hyphen are not allowed
in hostname.
Public IP The IP address on the public network for this 10.54.159.100 Yes
Address node.
Public IPv6 The IPv6 address on the public network for this fd00:10:6b50:4020::56/61 No
Address node.
(Optional)
Oracle VIP Virtual IP address that is assigned to Oracle 10.54.159.101 Yes

Clusterware or RAC.
iLO IP The IP address that is used to connect to the 10.54.163.52 Yes

Address iLO.

Private IP An IP address assigned to a device on a private If connected to IBM Yes
Address TCP/IP Local Area Network that is accessible DS3524 RAID, use
only within the Local Area Network.
192.168.128.1 as IP
Address for HP G8
If connected to IBM
V3700 RAID, use
192.168.70.1 as IP
address for HP G8
Node 2 (Secondary Server)
Hostname The name which identifies the system on the wfdems01b Yes
network.
The EMS hostname is limited in

length to 64 characters. The
hostname can only contain
lowercase letters [a-z] and digits
[0-9]. The hostname cannot start
with a digit. Special characters
including hyphen are not allowed
in hostname.
Public IP The IP address on the public network for this 10.54.159.102 Yes
Address node.
Public IPv6 The IPv6 address on the public network for this fd00:10:6b50:4020::56/62 No
Address node.
(Optional)
Oracle VIP Virtual IP address that is assigned to Oracle 10.54.159.103 Yes

Clusterware or RAC.
iLO IP The IP address that is used to connect to the 10.54.163.53 Yes

Address iLO.
Private IP An IP address assigned to a device on a private If connected to IBM Yes

Address TCP/IP Local Area Network that is accessible DS3524 RAID, use
only within the Local Area Network
192.168.128.2 as IP
Address for HP G8
If connected to IBM
V3700 RAID, use
192.168.70.2 as IP
Address for HP G8
Controller Management IPs (IBM V3700 RAID)
Array The array management 1 IP of IBM V3700 RAID 192.168.70.120 Yes

Management used by only one of the controller nodes, which
1 IP acts as the configuration node for creating or
modifying the configuration.

Array The array management 2 IP (floating IP) of IBM 192.168.70.123 Yes
Management V3700 RAID is plumbed with Ethernet port 2 of
2 IP each of the RAID controller node. The floating IP
is used to overcome the loss of ethernet
connectivity, which does not do a switchover and
RAID traps. The floating IP enables switchover of
controller in case of loss of Ethernet connectivity.
Array Controller IPs (IBM V3700 RAID)
Array The Array Controller A IP address for port 1 and 192.168.70.121 Yes
Controller A port 2 of IBM V3700 RAID.
IP
Array The Array Controller B IP address for port 1 and 192.168.70.122 Yes
Controller B port 2 of IBM V3700 RAID.
IP
Array Controller IPs (IBM DS3524 RAID)
Array The Array Controller A IP address for port 1 and 192.168.128.101 Yes
Controller A port 2 of IBM DS3524 RAID.
IP
Array The Array Controller B IP address for port 1 and 192.168.128.102 Yes
Controller B port 2 of IBM DS3524 RAID.
IP
The following summary outlines the key steps required to install EMS application for HA configuration.
Before proceeding with the EMS Application installation ensure the steps 1 to 5 to deploy both active and
standby HP DL380p Gen8 servers are completed.
Follow the instructions provided to cable the EMS HA cluster configuration.
Cabling is one of the most important aspects of planning for a HA configuration, this section guides you on cabling
the HP DL380p Gen8 servers with an external RAID.
Download and Prepare the Installation Files on both the HP DL380p Gen8 servers.

Install EMS application using iLO remote console on both the HP DL380p Gen8 servers.
Synchronize the primary and secondary EMS server time with the NTP server.
This step is used to synchronize the EMS time with NTP server.
Configure RAID and Network Bonding on the primary server.
This step performs the RAID configuration and network bonding. It is executed on the primary EMS server.
Install Oracle Clusterware and EMS cluster application on the primary server.
This step installs Oracle clusterware and completes the installations of EMS cluster application. It is executed on
the primary EMS server.
Perform the post-installation tasks.
This steps provides details about mandatory post-installation tasks.
Access the EMS GUI and Install EMS License using the License Manager utility in the EMS GUI.
This step is used to access the EMS GUI and install EMS licenses using License Manager.
Downloading Insight HA (on Linux) Installation Files
Download the following files from the Sonus Salesforce Customer Portal to perform the Insight installation using an
ISO image.
Table 17: Files to be downloaded from Salesforce
Insight HA ISO Image: emsrac-V09.03.00R000-RHEL-06.04.02.00R00 1. Download the emsrac-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso file from the Sonus
0-x86_64.iso Salesforce Customer Portal.
2. Place the file in a location, from where you can mount the iso for Insight installation.
Firmware File: Refer the file name on this page: https://support.sonus.net/displ For more information about HP firmware version and procedure to upgrade the HP firmware, refer the
ay/ALLDOC/HP+DL380p+G8+Firmware+Upgrade page https://support.sonus.net/display/ALLDOC/HP+DL380p+G8+Firmware+Upgrade.
PSX Manager GUI File: SSGUI_V09.03.00R000_RHEL.tar Download the SSGUI_V09.03.00R000_RHEL.tar file from the Sonus Salesforce Customer Portal
to the local system.
Updating the Date on the Server
Before installing the Insight HA application, you must run ntpdate on each server to provide the correct date. The
date changes while upgrading the iLO.
Perform the following procedure to update the date on the server:
1. Login as root user.

2. Enter the following command to stop the ntpd service.

# /sbin/service ntpd stop
3. Enter the following command to update the date on the server.
# ntpdate <NTP_SERVER>
24 Jun 10:27:55 ntpdate[2651]: adjust time server 10.128.254.67 offset
0.387661 sec
4. Enter the following command to start the ntpd service.
# /sbin/service ntpd start

Tue Jun 24 10:28:32 IST 2014
Starting ntpd:
After updating the date on the server, download the pre-configured configuration file for the Insight HA
application.
You can install the Insight HA application using any one of the following methods:
Setting up a configuration file with all the required parameters. (This is the recommended method)
or
Running the script in the interactive mode.
Kickstart the HP G8 Servers
On this page:
Downloading the ISO image

Installing RHEL OS
This section describes the procedure to install the Insight EMS HA Application on an HP DL380p G8 system using
the Insight EMS HA ISO Image provided by Sonus.
EMS installation cannot to be done using serial console.
Downloading the ISO image
The Insight HA ISO image is available in the Sonus Salesforce Customer Portal. Download the ISO image and
mount the image using iLO and install the Insight HA software.
Download the ISO image emsrac-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso from the Sonus

Salesforce Customer Portal and copy the image onto the machine from which you will be accessing the iLO.

Before installing EMS on multiple systems at the same time, make a copy of the image, because each
kickstart system needs its own unique copy of the ISO image or else the installation gets corrupted.
Installing RHEL OS
The ISO image installs the Operating System (Red Hat Enterprise Linux Server 6.4.2).
The rest of the installation can be launched after Insight HA installation is complete.
Perform the following procedure to kickstart the HP G8 servers on both the primary and non-primary servers:
1. To start the EMS installation we need to mount the ISO image using iLO of the HP Gen8 server.There are
two methods:
a. Using a Laptop physically connected to the HP Gen8 server through the iLO port
b. Using a PC or Laptop on the same network as the iLO
2. The CD-ROM EMSRAC Installer screen appears.
Figure 28: CD ROM Installer
3. Type 1 and press ENTER to start the EMSRAC Install using Monitor and Keyboard or Remote Console.
4. The following screen appears.

5. After a few minutes, the following screen appears and you can view the various RPM packages getting
installed.

The packages and post-installation scripts are executed automatically. This process may approximately take
30 minutes.
6. Unmount the virtual disk as CD ROM by selecting Virtual Drives and clear the Image File check box.

Figure 32: Unmount the Virtual Disk
7. Use the Tab key to select Reboot button. After selecting Reboot button, press Space key to reboot the
system.

8. Press F1 to continue booting the system or it continues by itself after some time.

Figure 34: F1_Key
9. When the system comes-up, you need to perform the network configuration. As part of Network
Configuration, you need to configure the Hostname, IP address for network interfaces, Time Zone, and Time
Server.
Select Hostname and press Space key configure the hostname for the system.


Figure 36: Hostname
b. Use the Arrow keys to select IP Configuration and press Space key to configure ip address. Select
'eth0' interface for which you need to configure the IP Address. Use the Tab key to select OK button
and press Space key to configure IP address for eth0 network interface.

c. Specify the IP Address, subnet mask, and gateway IP Address for eth0 network interface. Use the Tab
key to move the cursor to other parameter. Press Tab key to select OK and press Space key to save
IP Address details.
Installation can fail if correct IP address and Hostname is not provided.

d. Use the Arrow keys to select Time Zone and press Space key to configure the Time Zone. Select the
Zone settings.

Figure 39: Time Zone
e. After configuring Time Zone, Sonus Network Configuration screen is displayed. Select Time Server
f. Enter the NTP Time-Server IP Address, to synchronize the time for the host system and click OK.
Figure 40: NTP Server Configuration Screen

10.
The EMS application installation starts and after completing EMS Installation, login screen is
displayed. The steps 11 to 19 are optional and performed if you want to change the boot priority. If
you do not want to change the boot priority, skip steps 11 to 19 and refer from step20 onwards.
11. Press F9 to change the boot setup.

12. Select the Standard Boot Order (IPL) option and press ENTER.
The boot order appears.

Figure 42: Choice to select boot order
Figure 43: Updated Boot Order
15. Press ESC.


Figure 44: Confirmation to exit from BIOS Setup Utility
18. After the system reboots, the following Red Hat Enterprise Linux Server 6.4 startup screen appears.
Figure 45: Linux Startup Progress
19. After the system reboots, the system will display a screen showing the installation proceeding for the Brocade
drivers for the Fibre Channel card.

19.
Buffer I/O error on device sdc, logical block 0" error message might appear and you can ignore it.
Figure 46: Fibre Channel Installation Screen
This takes approximately 4 to 5 minutes, and then the system will reboot again.
20. The log in screen appears:

Figure 47: Login screen
21. Enter the login name and password.

The system then prompts to change the password. Type and confirm the new password.
Passwords should not contain the following:
a. Name or part of the name
b. Same letters
c. Patterns from keyboard (querty/wsxedc)
d. Repeated words or numbers (asdasdasd, 123123123)
e. Same letter or number repeated
f. Dictionary words
g. Reverse of all above
22. Enter the password again for confirmation.
23. Execute the following command to verify the platform version:
06.04.02.00R000
24. Execute the following command to verify the platform Kernel version:
# uname -r
2.6.32-504.3.3.el6.x86_64

For Post-installation or Upgrade Tasks, see Performing Post-Installation or Upgrade Tasks page.
Configuring RAID and Network Bonding on EMS Server
The RACinstall_1 script performs the network bonding and storage array configuration on the primary EMS
server (Node 1). You can run the RACinstall_1 script in an interactive mode or by providing an input configuration
file.
Sonus recommends you to use the input configuration template file instead of the interactive mode. For
details on filling-up the parameter values in the input configuration template, refer the section Pre-Installatio
n Checklist for EMS High Availability Configuration.
Perform any one of the following procedure based on the RAID array you are using:
Network Bonding and IBM V3700 RAID Array Configuration Network Bonding and IBM DS3524 RAID Array
Configuration
Network Bonding and IBM V3700 RAID Array Configuration
To configure network bonding and IBM V3700 RAID Array on the primary EMS server, perform any one of the
following procedure:
Executing RACinstall_1 Script using Input Configuration File for IBM V3700 RAID Array Executing RACinstall_1
Script in Interactive Mode for IBM V3700 RAID Array
Executing RACinstall_1 Script using Input Configuration File for IBM V3700 RAID Array
This section is relevant if you are executing the RACinstall_1 script using the input configuration file. The
RACinstall_1 script uses values set in the template configuration file thereby the script does not prompt you to
enter these values during the run time.
Topics inlcude:
Updating the Input Configuration File

Executing the RACInstall_1 Script
Perform the following procedure to configure the input values in the configuration file:
1. Login as root on the primary EMS server.

2. Navigate to the location cd /export/home/pkg
3. Execute the ls command and verify if rac.conf_3700.template exists.

3.
# ls
4. Create a backup of rac.conf_3700.template file, for future reference. Run the following command, to
create a backup of rac.conf_3700.template.
# cp rac.conf_3700.template /tmp/rac.conf
5. Change the permission of the copied file to write, using the following command:
# chmod +w /tmp/rac.conf
6. Manually edit the rac.conf file and fill in the parameter values matching your network setup using the vi
Editor. To edit the file, execute the following command:
Certain parameters in the rac.conf file have default values.
If IPv6 address (ipv6Support) parameter is set true then _node01_public_ipv6, _node02_pu

blic_ipv6, and sonusVIP.IPv6 should have the IPv6 length along with the IPv6 address. For
example: _node01_public_ipv6=fd00:10:6b50:5400::21/60, where 60 designates the
length.
# vi rac.conf
# Populate with the NTP server
_ntpServer=
# Populate with the name of the primary node (where install is being done
from)
_node01=
# Populate with the name of the secondary node

_node02=
# Populate with the public IP address of the primary node

_node01_public_ip=
# Populate with the public IP address of the secondary node

_node02_public_ip=
# Populate with the Oracle VIP of the primary node

_node01_public_vip=
# Populate with the Oracle VIP of the secondary node

_node02_public_vip=

# Populate with the unique name to be assigned to this RAC cluster
_clusterName=
# Populate with the shared IP address (IPv4) for this EMS cluster
sonusVIP.IPv4=
# Whether or not IPv6 support is enabled (true/false)

ipv6Support=false
# Populate with the public IPv6 address of the primary node

_node01_public_ipv6=
# Populate with the public IPv6 address of the secondary node

# Populate with the public IPv6 gateway address

_public_ipv6_gateway=
sonusVIP.IPv6=
# For all of the rest of the properties, defaults are provided

# and may not need to be changed
# Populate with the private IP address of the primary node

_node01_private_ip=192.168.70.1
# Populate with the private IP address of the secondary node

# Populate with the netmask used for the private IP addresses

_private_netmask=255.255.255.0
# Populate with the service IP address (private network) of Controller 1 of

# the IBM-3700 storage array.
_array_controllerA_IP=192.168.70.121
# Populate with the service IP address (private network) of Controller 2 of

# the IBM-3700 storage array.
_array_controllerB_IP=192.168.70.122
_array_management1_IP=192.168.70.120
_array_management2_IP=192.168.70.123

_storage_type=3700FC
7. After updating the values, press ESC key and enter :wq! to save the configuration.
Prerequisites
Before running the installation scripts (./RACinstall_1), ensure that both the paths connected to the IBM
V3700 RAID are reachable. In case, if one of the paths connected to the IBM V3700 RAID is not reachable then
installation script exits prompting you to first check the fibre channel connections. For example, if a wrong cable
is connected to external RAID, the path might not be reachable and the following error message is displayed:
Error: One or more FC ports are down on node. Please check fibre
channel connections on node.
WORKAROUND: Fix the RAID connectivity issue and re-run the RACinstall_1 script.
1. Login as root on the primary EMS server.

2. Navigate to the following location:
3. Enter the following command to execute the script:
# ./RACinstall_1 /tmp/rac.conf
The following output is displayed:
Executing the RACinstall_1 command performs initialization of IBM V3700 RAID and also
creates volumes on the V3700 RAID.

Building RAC configuration locally .....
Executing /export/home/pkg/EMSbuild_config .............................. (ok)
Configuring /etc/hosts locally .......................................... (ok)
Building node list ...................................................... (ok)
Copying RAC configuration to eole ....................................... (ok)
Configuring /etc/hosts on eole .......................................... (ok)
Configuring NTP on suzaku ............................................... (ok)
Configuring NTP on eole ................................................. (ok)
Configuring network bonding on suzaku ................................... (ok)
Configuring network bonding on eole ..................................... (ok)
Re-Setting V3700 storage array (this will take awhile) .................. (ok)
Initializing V3700 storage array (this will take awhile) ................ (ok)
Creating volume and mapping to suzaku ................................... (ok)
Mapping volume to eole .................................................. (ok)
Executing /export/home/pkg/EMSconfig_3700 on suzaku ..................... (ok)
Executing /export/home/pkg/EMSconfig_3700 on eole ....................... (ok)
Rebooting eole .......................................................... (ok)
Rebooting suzaku ........................................................
Broadcast message from root@suzaku
(/dev/pts/0) at 13:19 ...
The system is going down for reboot NOW!
After the script runs, both the primary and secondary server reboots.
The RACinstall_1 script takes approximately 15 to 20 minutes to complete.
Executing RACinstall_1 Script in Interactive Mode for IBM V3700 RAID Array
This section is applicable if you are executing the RACinstall_1 script in the interactive mode.
Prerequisites
Before running the installation scripts (./RACinstall_1), ensure that both the paths connected to IBM V3700
RAID are reachable. In case, if one of the paths connected to external RAID is not reachable then installation
script exits prompting you to first check the fibre channel connections. For example, if a wrong cable is
connected to external RAID, the path might not be reachable and the following error message is displayed:
1. Login as root to the EMS primary server.


2.
cd /export/home/pkg
# ./RACinstall_1
The following prompt appears:
Please enter cluster name ->
4. Enter the cluster name. For example, emscluster.

5. After entering the cluster name, press ENTER to continue.
Please enter private netmask [255.255.255.0] ->
The default netmask is displayed. For example, [255.255.255.0]

If you want to use the default value, press Enter to continue.
OR
If you do not want to use the default value, then enter the required value and press Enter to continue.
6. The following prompt appears:
Please enter storage array type (3524FC or 3700FC)->
Type 3700FC and press Enter to continue.

Please enter IP addr. of array controller A [192.168.70.121] ->
Press Enter to use the default value or enter the required value and press Enter to continue.
Please enter IP addr. of array controller B [192.168.70.122] ->

9.
Please enter management IP 1 of storage array [192.168.70.120] ->
Please enter management IP 2 of storage array [192.168.70.123] ->
Please enter NTP server IP ->
Enter the NTP server IP. For example, 10.128.1.1 and then press Enter to continue.
Please enter node 1 hostname ->
Enter the node 1 hostname. For example, emshost1 and then press Enter to continue.
Please enter node 1 public IP ->
Enter the node 1 public IP. For example, 10.2.2.2 and then press Enter to continue.
Please enter node 1 public VIP ->
Enter the node 1 public VIP. For example, 10.2.2.3 and then press Enter to continue.
Please enter node 1 private IP [192.168.70.1] ->
Enter the required value and press Enter to continue.


The following message appears:
Executing /export/home/pkg/EMSbuild_config...... .
20. The following message appears:
Please enter Shared Virtual EMS VIP ->
Enter the Shared Virtual EMS VIP. For example, 10.2.2.6 and then press Enter to continue
21. The following message appears if you want to enable or disable IPv6.
Please enter whether to enable IPv6 (true/false) ->
22. If you want to disable IPv6, enter (false) and then press Enter to continue.
Or
23. If you want to enable IPv6, enter (true) and then press Enter to continue.
Please enter node 1 public IPv6 address
Enter the node 1 public IPv6 address. For example, fd00:10:6b50:53a0::bf/60 then press Enter to continue.

24.
Please enter node 2 public IPv6 address ->
Enter the node 2 public IPv6 address. For example, fd00:10:6b50:53a0::c1/60 and then press Enter to
continue.
Please enter Public IPv6 Gateway ->
Enter the Public IPv6 Gateway address. For example, fd00:10:6b50:53a0::1 and then press Enter to
continue.
Please enter Shared Virtual EMS IPv6 VIP. ->
Enter the Shared Virtual EMS IPv6 VIP address. For example, fd00:10:6b50:53a0::ca/60 and then press
Enter to continue.
The output displayed is similar in both the interactive and non-interactive mode.
If the script prompts for the RAID password after the following outputs, please enter the pre-existing
RAID password.
Configuring network bonding on emshp1 ........ (ok)

Configuring storage array from emshp1 .........(ok)
27. After the script runs, both the primary and secondary server reboots.
The RACinstall_1 command takes approximately 15 to 20 minutes to complete.
Network Bonding and IBM DS3524 RAID Array Configuration
To configure network bonding and IBM DS3524 RAID Array on the primary EMS server, perform any one of the
following procedure:
Configuring IBM DS3524 Storage Subsystem Controller IP Address Executing RACinstall_1 Script using Input
Configuration File for IBM DS3524 RAID Array Executing RACinstall_1 Script in Interactive Mode for IBM DS3524
RAID Array

Configuring IBM DS3524 Storage Subsystem Controller IP Address
If you are not using the default values for private IP addresses, then you need to configure the IBM RAID
controller IP address.
The IBM DS3524 storage subsystem has two controllers that are hot-swappable and redundant. The controllers
contain the storage subsystem control logic, interface ports, and LEDs.
Each controller contains the following ports:
The two SAS 2.0 host ports are not used in the EMS HA solution.
Two SAS 2.0 host ports labeled 1 and 2. Each of them are x4 multilane, 6 Gbps universal
mini-SAS ports.
Two Ethernet management ports labeled 1 and 2 for Out-Of-Band management
The port (2) on the extreme right is a x4 multilane mini-SAS port for connecting to
EXP3524 drive expansion enclosures
Four Fibre Channel ports labeled FC 3 through 6. Each of these ports is capable of
operating at 8 Gbps, 4 Gbps, or 2 Gbps.
The Ethernet ports have the following default IP addresses:
Port 2 is not used in the EMS HA solution.
Port 1 on controller A is 192.168.128.101

Port 1 on controller B is 192.168.128.102
The subnet mask for both Ethernet ports is 255.255.255.0.
Installation of Storage Manager for DS3524
Perform the following steps to install the Storage Manager for DS 3524:
1. Login as root user and change the directory to

/opt/sonus/platform/IBMDS3524_FW07864000_SM1086X543/
# cd /opt/sonus/platform/IBMDS3524_FW07864000_SM1086X543/
2. Execute the installation script INSTSM1086X543 to install DS 3524 Storage Manager.
# ./INSTSM1086X543
Setting the IP Address of Each DS3524 Storage System Controller

Perform the following procedure to assign an IP address to a DS3524 storage subsystem controller. This procedure
must be performed twice, once for Controller A and once for Controller B.
You can set the IP address of DS3524 Storage system as follows:
Setting the IP Address through X-server

1. Connect the HP DL380p G8 server to a simple Hub/Switch after installing on both the HP DL380p G8
servers.
2. Connect Ethernet port 2 on each DS3524 controller to the same Hub/Switch which is connected to your HP
DL380p G8 servers. This must be done only on one machine. It can be either active or standby.
For dual controller models, both controllers need to be accessible.
3. Start the X-server (such as Exceed) on the system where the GUI is to be launched.
4. Set the DISPLAY variable's IP address to the IP address of the machine where the GUI should be launched
using the following commands:
DISPLAY=<IP Address>:0.0
export DISPLAY
echo $DISPLAY
Where <IP Address> is the IP of the machine where the GUI need to be launched.
5. Login as root to the HP DL380p G8 server which is connected to the same Hub/Switch and go to the
/opt/IBM_DS/client directory:
# cd /opt/IBM_DS/client
6. Run the Storage Manager client.
# ./SMclient
The Enterprise Management Window opens.

Since Storage Manager is GUI-based application, set your DISPLAY to display graphics.
7. Click on the Add Storage Subsystem link from the Setup tab in the DS Storage Manager Enterprise
Management window.
The Select Addition Method-Manual screen opens.
8. In the Select Addition Method-Manual screen, select the Automatic discovery button and click OK.
9. Click OK to begin an initial automatic discovery of hosts on storage subsystems.
After the initial automatic discovery is complete, the Devices tab of the Enterprise Management Window
displays all hosts and storage subsystems attached to the local subnetwork.
The Enterprise Management Window can take up to a minute to refresh after an initial automatic
discovery.
10. In the Subsystem Management window, right-click the discovered storage subsystem to see the context
menu with the tasks.

10.
Select the Manage Storage Subsystem task.

11. When you choose to manage a specific storage subsystem, the IBM System Storage DS (Subsystem
Management) window opens, along with the Initial Setup Task on background and a small window prompting
for the password.
Enter the password for Subsystem.
12. In the IBM System Storage DS (Subsystem Management) window, click the Configure Ethernet Management
Ports link in the Optional Task list.
The Change Network Configuration screen opens.
The following is the default port IP addresses for controller A:
192.168.128.101 - Port 1
The following is the default port IP addresses for controller B:
defaults again for controller B if you want:
192.168.128.102 - Port 1
13. In the Change Network Configuration screen, change the default Port IP addresses to your local IP
addresses.
14. Close the Storage Manager client.
Setting the IP Address through Windows Manager
The IP address of IBM RAID storage system controller can be configured through the following windows
configuration tool. The software is packaged along with the EMS and is available in the directory
/opt/sonus/platform/IBMDS3524_FW07832700_SM1083X523 on the EMS server.
The file ibm_sw_ds3-5k_10.84.xx.30_windows_intl386.zip should be copied to a windows 32-bit laptop.
This software only runs on windows 32-bit machines
1. In the windows system, extract the ibm_sw_ds3-5k_10.84.xx.30_windows_intl386.zip file.

2. Execute the installation file SMIA-WS32-10.84.x5.30.exe from the following path
WS03WS08_10p84_IA32\Windows\ to start the installation.
Figure 48: Windows Manager
3. After the installation preparation, the IBM System Storage DS Storage Manager screen appears. Select the
language as ‘English’ from the drop-down box and click OK.

Figure 49: IBM Storage Manager
The IBM System Storage DS Storage Manager configuration process starts up as shown in the following
figure.

Figure 50: IBM Storage Manager Process
4. The IBM System Storage DS Storage Manager is configured on the system.

Figure 51: Install IBM DS Storage Manager
5. Click Next to continue.

6. The copyright information screen is displayed. Click Next to continue.

Figure 52: IBM DS Storage Manager
7. Read the License Agreement and select I accept the terms of the License Agreement, then Click Next to
continue.

Figure 53: IBM Storage Manager
8. The default path of installation is displayed. Click Choose to select the installation folder as you required, the
click Next to continue.

Figure 54: IBM Storage Manager Install Path
9. Select the installation type as Typical (Full Installation) and click Next to continue.

Figure 55: IBM Storage Installation Type
10. Select the Automatically Start Monitor (Recommended) option to start monitoring automatically after
installation and click Next to continue.

Figure 56: IBM DS Storage Start Monitor
11. The IBM System Storage DS Storage Manager installation specifications getting configured on the system.
Click Next to continue.

Figure 57: IBM Storage Manager Configured
12. Verify that sufficient disk space is present and click Install.

Figure 58: IBM Storage Manager Space Requirements
13. The IBM System Storage DS Storage Manager 10 installation process is displayed as shown below.

Figure 59: IBM Storage Manager process
14. After the installation completes, click Done button.

15. Connect the laptop to the same network where the IBM RAID systems exist, and start the DS Storage
Manager 10 Client.
16. Select automatic option, and click OK to begin an initial automatic discover of host on storage subsystem.

Figure 60: IBM DS Storage Manager Addition
After the initial automatic discovery is completed, the device tab of Enterprise Management window displays
all hosts and storage subsystems attached to the local subnetwork.
The Enterprise Management window can take up to a minute to refresh after an initial automatic
discovery.
menu with this tasks.
Management) window appears along with the Initial Setup Task on background and a small window prompts
for the password.
Enter the password for subsystem.
Ports link from the Optional Task list.
The Change Network Configuration screen appears:
The default port IP address for controller A is:
192.168.128.101 - Port1
The default port IP address for controller B is:
192.168.128.102 - Port2
20. In the Change Network Configuration screen, change the default Port IP address to your local IP address.
21. Close the DS Storage Manager 10 Client.
Executing RACinstall_1 Script using Input Configuration File for IBM DS3524 RAID Array
This section is relevant if you are executing the RACinstall_1 script using the input configuration file. The

RACinstall_1 script uses values set in the template configuration file thereby the script does not prompt you to
enter these values during the run time.

Perform the following procedure to configure the input values in the configuration file:
1. Login as root user on the primary server.

3. Execute the ls command to verify if the rac.conf_3524.template file exists.
# ls
4. Create a backup of rac.conf_3524.template file, for future reference. Run the following command, to
create a backup of rac.conf_3524.template.
# cp rac.conf_3524.template /tmp/rac.conf
5. Change the permission of the copied file to write, using the following command:
# chmod +w /tmp/rac.conf
6. Manually edit the rac.conf file and fill in the parameter values matching your network setup using the vi
Editor. Edit the configuration file by executing the following command:
Certain parameters in the rac.conf file have default values.
If IPv6 address is set to true then _node01_public_ipv6, _node02_public_ipv6, and sonus

VIP.IPv6 should have the IPv6 length along with the IPv6 address.
For example: _node01_public_ipv6=fd00:10:6b50:5400::21/60, where 60 designates the
length.
# vi rac.conf

_ntpServer=
from)
_node01=

_node02=

_node01_public_ip=

_node02_public_ip=

_node01_public_vip=

_node02_public_vip=

_clusterName=
sonusVIP.IPv4=

ipv6Support=false



sonusVIP.IPv6=




# Populate with the IP address (private network) of Controller A of

# the IBM DS3524 storage array.
# Note that controller IPs are not required for a VM based setup
_array_controllerA_IP=192.168.128.101
# Populate with the IP address (private network) of Controller B of

# the IBM DS3524 storage array.
_array_controllerB_IP=192.168.128.102
_storage_type=3524FC
7. After updating the values, press ESC key and enter :wq! to save the configuration.
Prerequisites
Before running the installation scripts (./RACinstall_1), ensure that both the paths connected to the IBM
DS3524 RAID are reachable. In case, if one of the paths connected to external RAID is not reachable then
installation script exits prompting you to first check the fibre channel connections. For example, if a wrong cable
is connected to external RAID, the path might not be reachable and the following error message is displayed:
1. Login as root to the EMS primary server.

# ./RACinstall_1 /tmp/rac.conf

Copying RAC configuration to belgrade ................................... (ok)
Configuring /etc/hosts on belgrade ...................................... (ok)
Configuring NTP on harare ............................................... (ok)
Configuring NTP on belgrade ............................................. (ok)
Configuring network bonding on harare ................................... (ok)
Configuring network bonding on belgrade ................................. (ok)
Installing Storage Manager (SM) on harare ............................... (ok)
Installing Storage Manager (SM) on belgrade ............................. (ok)
Configuring DS3524 storage array from harare (this will take awhile) .... (ok)
Configuring DS3524 storage array from belgrade (this will take awhile) .. (ok)
Executing /export/home/pkg/EMSconfig_3524 on harare ..................... (ok)
Executing /export/home/pkg/EMSconfig_3524 on belgrade ................... (ok)
Rebooting belgrade ...................................................... (ok)
Rebooting harare ........................................................
If the script prompts for the RAID password, please enter the pre-existing RAID password.
After the script runs, both the primary and secondary server reboots.
The RACinstall_1 script takes approximately 15 to 20 minutes to complete.
Executing RACinstall_1 Script in Interactive Mode for IBM DS3524 RAID Array
This section is applicable if you are executing the RACinstall_1 script in the interactive mode.
Prerequisites
Before running the installation scripts (./RACinstall_1), ensure that both the paths connected to IBM DS3524
are reachable. In case, if one of the paths connected to external RAID is not reachable then installation script
exits prompting you to first check the fibre channel connections. For example, if a wrong cable is connected to
external RAID, the path might not be reachable and the following error message is displayed:
1.

1. Login as root to the primary EMS server.
cd /export/home/pkg
3. Enter the following command:
# ./RACinstall_1
Please enter cluster name ->
Enter the cluster name. For example, emscluster.

After entering the cluster name, press ENTER to continue.
Please enter private netmask [255.255.255.0] ->
The default value is displayed. For example, [255.255.255.0]

If you want to use the default value, press Enter to continue.
If you do not want to use the default value, then enter the required value and press Enter to continue.
Please enter storage array type (3524FC or 3700FC)->
Type 3524FC and press Enter to continue.
Please enter IP addr. of array controller A [192.168.128.101] ->
Press Enter to use the default value.

Or
Enter the required value and press Enter to continue.
Please enter IP addr. of array controller B [192.168.128.102] ->
9.

Please enter NTP server IP ->
Enter the NTP server IP. For example, 10.128.1.1 and then press Enter to continue.
Enter the node 1 public VIP.

For example, 10.2.2.3 and then press Enter to continue.

16.
Executing /export/home/pkg/EMSbuild_config...... .
Please enter Shared Virtual EMS VIP ->
Enter the Shared Virtual EMS VIP. For example, 10.2.2.6 and then press Enter to continue
19. The following message appears if you want to enable or disable IPv6
Please enter whether to enable IPv6 (true/false) ->
20. If you want to disable IPv6, enter (false) and then press Enter to continue.
Or
21. If you want to enable IPv6, enter (true) and then press Enter to continue.
Enter the node 1 public IPv6 address. For example, fd00:10:6b50:53a0::bf/60 then press Enter to continue.
Enter the node 2 public IPv6 address. For example, fd00:10:6b50:53a0::c1/60 and then press Enter to
continue.

23.
Please enter Public IPv6 Gateway ->
Enter the Public IPv6 Gateway address. For example, fd00:10:6b50:53a0::1 and then press Enter to
continue.
Please enter Shared Virtual EMS IPv6 VIP. ->
Enter the Shared Virtual EMS IPv6 VIP address. For example, fd00:10:6b50:53a0::ca/60 and then press
Enter to continue.
The output displayed is similar in both the interactive and non-interactive mode.
If the script prompts for the RAID password after the following outputs, please enter the pre-existing
RAID password.

Configuring storage array from emshp1 .........(ok)
25. After the script completes, both the primary and secondary server reboots.
The RACinstall_1 script takes 15 to 20 minutes approximately to complete.
Installing Oracle Clusterware and EMS Cluster Application
Perform the following procedure to install Oracle Clusterware and EMS Application on the primary server.
Ignore the following errors, unless DB Instance creation fails. The following errors are seen on trace/alert
$ORACLE_BASE/admin/SIDB/udump/diag/rdbms/<ORACLE_SERVICE_NAME>/$ORACLE_SID/trace
Error Codes:
ORA-00942
ORA-942
The cluster name must be at least one character long and no more than 15 characters in length, must be
alphanumeric, and may contain hyphens.
This procedure approximately takes one hour to complete.
To view the progress of the installation, open another session and view latest log files at /var/sadm/inst
all/logs
1.

1. Before you execute the ./EMSRACinstall script, ensure that ClusterName-Scan and the three scan
IP-address entries are added into the domain-name in DNS.
As a root user on the primary host, execute the command nslookup <clustername-scan>.
When you try to resolve the ClusterName-Scan, the Scan IPs must be resolved. As shown in the following
example:
# nslookup Prim1Sec2-scan
Server: 10.34.13.200
Address: 10.34.13.200#53
Address: 10.56.166.5
Address: 10.56.166.6
Address: 10.56.166.7
2. As a root user on the primary host, navigate to the following location:
3. Run the following command:
# ./EMSRACinstall
4. The system displays the following output:

Discovering WWID of ASM device .......................................... (ok)
...<command output cut for brevity>...
Configuring I/O multipathing autostart on eole boot ..................... (ok)

Setting up user equivalence ............................................. (ok)
The following messages on GRID and RDMS will appear for a long time and it takes an hour to complete.
Installing GRID software (this will take awhile) ........................ (ok)

Installing RDBMS software (this will take awhile) ....................... (ok)
Creating ASM directory .................................................. (ok)
The following message on DBCA will appear for a long time:

Invoking DBCA to create new database (this will take awhile) ............ (ok)
Re-setting initialization parameters .................................... (ok)
Stopping the database ................................................... (ok)
Starting the database ................................................... (ok)
The following message on calling schema will appear for a long time:
Calling schema creation script (EMSdbschema.sh) ......................... (ok)

Bouncing database ....................................................... (ok)
Completing database install ............................................. (ok)
The following message on Installing EMS will appear for a long time:
Installing EMS software on localhost .................................... (ok)
The following message on remote installation will appear for a long time:
Performing remote installation on eole. Please wait ..................... (ok)
Registering EMS processes under Clusterware.............................. (ok)

Starting all of the EMS processes via Clusterware........................ (ok)
Completed EMS installation .............................................. (ok)
5. All the Insight processes are automatically started as part of the installation.
6. The Insight HA installation is complete.
# rpm -qa SONSems
SONSems-V09.03.00-R000.x86_64
8. Login as oracle user and execute following command to verify Oracle database version:
$ sqlplus -version

9. Login as oracle user and execute following command to verify the latest Oracle database patch version:

Oracle patch version must be Patch description: "Database Patch Set Update : 11.2.0.3.0 (19271438)"
Each script in the installation sequence generates its own log. The installation log files are found on the
primary node at /var/sadm/install/logs.If there are errors during the installation, refer to RACinstal
l_1.<id>.log and RACinstall_2.<id>.log and EMSinstall.<id>.log.The DB installation log
files are located at /opt/oracle/orasql/SIDB01 on the primary node.
The ./EMSRACinstall command takes approximately 1 hour - 1 hour 10 minutes to complete.
Upgrading the IBM V3700 RAID Firmware Version
For more detail about latest IBM V3700 RAID firmware version and how to perform firmware upgrade, refer the
section IBM Storwize V3700 Firmware Upgrade Quick Start.
Post-Installation Tasks on EMS HA

Configuring the NTP Server

Upgrading the IBM V3700 RAID Firmware version
For password related information, refer the section

Managing Insight Account Names and Passwords".
You need to select an NTP server for your network. The installation process requires only one NTP server.
However, it is recommended that you add a second NTP server after you complete the installation process. The
second server acts as a backup server, in case the primary NTP server goes down.
You must add a second NTP server only after the installation is complete.
Perform the following procedure to add a second NTP server:

2.

2. Using the vi editor, edit /etc/ntp.conf file and add the second server IP address.
server <ntp_server_ip_address / hostname>
For example:
# server 127.127.1.0
3. Enter the following command to restart the ntp server.
# /sbin/service ntpd restart

Starting NTP service .................................................... Fri
May 31 20:40:53 IST 2013
Starting ntpd: [ OK ]
(ok)
1. Login to the EMS primary and secondary servers as root user.

2. Perform the following steps on both the primary and secondary server to verify if the PSX Manager GUI
version is the latest:
wards.

PSX V09.03.00R000
3. Login to the primary server as root user.

4. Stop EMS on primary and secondary server as user insight, by executing following command on primary
server:
# su - insight
$ /opt/sonus/ems/conf/HA/RAC/sonusEMS stopAll
5. Login to the EMS primary server as root user.

system.

9.
# ./GuiClient.sh
SONSems-V09.03.00-R000.x86_64
SONSpsx-V09.02.00-R000.x86_64

Removing SONSpsx.
Installing SONSpsx.
Preparing... ########################################### [100%]
1:SONSpsx ########################################### [100%]

PSX V09.03.00R000
14. Login to the EMS secondary server as root user.
15.

15. Perform steps from step 6 to step 13 on EMS secondary server to install PSX Manager GUI.
16. Start EMS on the primary and secondary server as user insight, by executing the following command on EMS
Primary system:
# su - insight
$ /opt/sonus/ems/conf/HA/RAC/sonusEMS startAll
17. Login to the EMS GUI on the EMS Primary and Secondary systems.
do the following:

If the HP Firmware version is the not the latest then upgrade the HP Firmware to the latest version,
by performing the following steps.
4. Upgrade HP Firmware on non-primary (automatically reboots). For upgrading firmware, refer HP DL380p G8
Firmware Upgrade.
5. Relocate EMS (making non-primary active).
6. As user root, enter the following command on the primary server, which is active:
# cd /opt/sonus/ems/conf/HA/RAC
# ./sonusEMS relocate
7. Upgrade HP Firmware on primary (automatically reboots). For upgrading firmware, refer HP DL380p G8
Firmware Upgrade.
8. Relocate EMS by making primary as active.
9. As user root, enter the following command on the non-primary server, which is active:

The primary server again becomes the active server.
10. The above procedure completes the upgrade firmware for HA setup.
If you are upgrading EMS SWe for KVM or VMware ESXi, upgrading IBM V3700 RAID firmware is not
required. Upgrading IBM V3700 firmware is applicable only for EMS HA physical server-based upgrade.
Verify if the IBM V3700 firmware is the latest version. For IBM V3700 Firmware latest version and procedure to
upgrade the Firmware, refer the page IBM Storwize V3700 Firmware Upgrade Quick Start.
Installing EMS V09.03.00 removes the previous device manager (DM) on the system, if it was installed earlier. After
installing EMS 9.3.0, install the respective DM supported for EMS 9.3.0. For more information on Device Manager,
see the SBC Manager section of the Insight User Guide. For more information on installing or upgrading Device
Manager, refer Installing and Upgrading Device Manager (DM).
The following summary outlines the key steps required to install EMS application for HA configuration.
Before proceeding with the EMS Application installation ensure the steps 1 to 5 to deploy both active and
standby HP DL380p Gen8 servers are completed.
Follow the instructions provided to cable the EMS HA cluster configuration.
Cabling is one of the most important aspects of planning for a HA configuration, this section guides you on cabling
the HP DL380p Gen8 servers with an external RAID.
Skip to Step 4, if you are using IBM V3700 Array.
If you are using IBM DS3524 storage array, configure the RAID controller IP address.
Download and Prepare the Installation Files on both the HP DL380p Gen8 servers.
Install EMS application using iLO remote console on both the HP DL380p Gen8 servers.

Synchronize the primary and secondary EMS server time with the NTP server.
This step is used to synchronize the EMS time with NTP server.
Configure RAID and Network Bonding on the primary server.
This step performs the RAID configuration and network bonding. It is executed on the primary EMS server.
Install Oracle Clusterware and EMS cluster application on the primary server.
This step installs Oracle clusterware and completes the installations of EMS cluster application. It is executed on
the primary EMS server.
Perform the post-installation tasks.
This steps provides details about mandatory post-installation tasks.
Access the EMS GUI and Install EMS License using the License Manager utility in the EMS GUI.
This step is used to access the EMS GUI and install EMS licenses using License Manager.
Setup DR connectivity between source and target DR Sites
This step is used to setup the DR connectivity between the source and target DR sites. It is executed on the
source DR site.
Setting Up DR on EMS Source HA System
This section provides information on setting up DR on EMS source High-Availability (HA) system.
Prerequisites for setting up DR:
Ensure that following prerequisites are met, before setting up DR configuration:
The EMS HA installation should be completed on both the Source and Target systems.
The EMS should be running on the Source and Target systems.
Both the Target EMS systems should be accessible from the Source EMS systems, and
vice versa.
To setup DR on EMS source primary system, perform the following steps:
1. Change directory to /opt/sonus/ems/conf/DR by executing following command:
# cd /opt/sonus/ems/conf/DR
2. Execute the ./manageDR setup command to setup DR:
# ./manageDR setup
3. A confirmation message to setup DR is displayed. Press y when the following prompt appears:

3.
4. Enter the Target EMS primary system IP address when the following prompt appears:
The DR Setup configures the source and target EMS systems for replication, backs up the database in the
source system, restores it on the target system, and initiates the replication process.
To verify the DR configuration on the HA system, perform the following steps:
1. Change directory to /opt/sonus/ems/conf/DR, using the following command:
2. Execute the command ./manageDR status to verify the DR configuration.
# ./manageDR status
The system displays a message showing the system configuration details.
This section provides information on upgrading HA EMS system on Linux platform. Moreover, this section provides
information for upgrading EMS HA for a DR configuration.

Back to Table of Contents.
Post-Upgrade Steps
Rollback EMS HA
In this section:
ISO image. The EMS ISO upgrade method enables you to upgrade the operating system and database apart from
upgrading the EMS application software.
The ISO upgrade method performs an upgrade of EMS Application, Linux OS (if needed), Oracle database
(if needed) and Oracle security patch updates (if needed) for EMS HA or EMS HA DR configuration.
Table 18: Examples of Upgrade Paths and Supported Upgrade Methods
V08.04.07 V09.03.00 ISO Upgrade
V09.00.00 V09.03.00 ISO Upgrade
V09.01.00 V09.03.00 ISO Upgrade
V09.01.04 V09.03.00 ISO Upgrade
V09.02.00 V09.03.00 ISO Upgrade
V09.03.00 V09.03.01 ISO Upgrade

ISO image emsrac-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso available in WL9.3 Software
Bundle the Sonus Salesforce Customer Portal. The EMS ISO image includes Linux Operating System, EMS
application, and EMS database packages. For EMS HA upgrade, only INPLACE upgrade type is applicable.
The INPLACE upgrade type enables you to upgrade the EMS software application, operating system, and
database to the latest release versions. The benefit of INPLACE upgrade type is that it upgrades the OS, database
and EMS application without reinstalling them.
You may need to plan a longer upgrade maintenance window, if you are upgrading from earlier EMS
releases such as V08.04.07R000 to V09.03.00. The EMS upgrade takes longer depending on the number
of rows in the IPTRUNKGROUPINTERVALSTATS table. Sonus recommends to reorder the columns in
the IPTRUNKGROUPINTERVALSTATS table in a maintenance window prior to upgrading EMS. For more
information, contact Sonus Customer Support.
The following are prerequisites for upgrading Insight EMS HA deployment or EMS DR site with HA servers from
software release 9.1.x to 9.3.x are as follows:
server name, refer Changing Netcool DB Object Server Name for EMS HA.
Backup data and copy it to a remote system, before performing an EMS HA Upgrade. System backup is
critical and can be used, if EMS upgrade fails to restore the data. For more information on how to backup,
refer the section System backup.
Both the primary and the secondary servers must be Up and Running.
You can check the current status of both the primary and secondary servers, using the /opt/sonus
/ems/conf/HA/RAC/sonusEMS status command.
Both the primary and secondary servers are installed with Insight EMS software release 9.1.x.
You have read the latest Sonus Insight release notes for important information.
You should be aware of the Insight account and default passwords.

To avoid shortage of disk space, remove previous release directories created in the path /opt/ems
Install/. For example, while upgrading to Release V09.02.00, you might have created new
directory 9.2 in the path /opt/emsInstall/. To reclaim space occupied by previous-release
folders under /opt/emsInstall/, you can remove the previous release directories, using the
following command:
For Example:
You have terminal access to the servers on which you are upgrading the Insight.
The primary and non-primary servers meet the minimum hardware requirements.
Ensure that Active EMS must be running on the Primary EMS server, prior to the EMS upgrade procedure.
Primary node can be determined by executing the following command:
$ cat /etc/rac.conf | grep _node01=
Similarly, Secondary node can be determined by executing the following command:
In case primary is not Active, switchover needs to be done using sonusEMS relocate command.
Do not execute the EMS upgrade procedure on a SSH window where it is connected through the Cluster
virtual or logical IP address.
Login through the physical IP address on EMS interface eth0.
The EMS upgrade procedure must be executed as superuser "root".
Do not ‘su’ to root from a different user-id.
System Backup
Before upgrading EMS HA, backup EMS data and copy it to remote server. Backup of data is needed in case if EMS
upgrade fails.
1. Log on to the active system as a user with root privileges.

2. Run the manualBackup.sh script using the following commands on the active system:

The backup results in the creation of backupFiles.tar anddmp files in the backup directory. Copy the
backup files to a remote server, which enables restore of data later in case if EMS upgrade fails.
The following table provides list of files to be downloaded for ISO upgrade:
ISO Upgrade Files
emsrac-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso
upgradeEMS.sh
Firmware File

For Example:

links in the WL9.3 software bundle.
The ISO file Perform the following steps to download emsrac-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso and upgr
emsrac-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso adeEMS.sh files:
updates. The ISO file must be stored in the same path
where upgradeEMS.sh script is downloaded.
are upgrading. For example, to upgrade to 9.3 release, instead of <NEW_EMS_VERSION> s
pecify 9.3 as directory name. The directory <NEW_EMS_VERSION> where you are
perform ISO upgrade. The upgradeEMS.sh file performs all
downloading the file, must be empty and must not contain other files. Ensure that the
the necessary tasks such as system checks, create backup
directory allows any user to read and execute the files and has enough space for
of configuration, upgrade OS, Database and EMS
extracting Insight upgrade files.
Application.
1. Login to the shell on the Primary EMS server as root user.

Example: To upgrade to 9.3, execute following command to create a directory:
# mkdir -p /opt/emsInstall/9.3/
3. Download the emsrac-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso and upgradeEMS.sh file available under

WL9.3 Software Bundle from the Sonus Salesforce Customer Portal to /opt/emsInstall/<NEW_EMS_VERSION>/
directory on the Primary EMS server.
5. Change the execute permission of upgradeEMS.sh file by executing the following command:
Firmware Upgrade
Download the HP firmware file and verify if the HP firmware version is the latest. For more information about
HP firmware latest version and procedure to upgrade the HP firmware, refer the page https://support.sonus.
net/display/ALLDOC/HP+DL380p+G8+Firmware+Upgrade.
If you are upgrading EMS SWe for KVM, upgrading iLO is not required. Upgrading iLO firmware is
applicable only for EMS physical server-based upgrade.
This is the HP G8 DL380 firmware upgrade file. Ensure that the HP DL380 G8 firmware is upgraded after Download the firmware file from Salesforce Customer Portal to: /opt/sonus/p
you perform the EMS Software upgrade. latform directory in the server.

The following summary outlines the key steps required to upgrade EMS HA server using ISO upgrade. Perform
these steps on the EMS primary server only.
This step identifies the required upgrade files for download to the EMS primary server and how to prepare the files
for upgrade.
Manually Backup EMS Data.
This step is used to manually backup EMS database and configuration on a regular basis.
Set backup values in upgrade configuration file.
This step is used to set the backup related parameter values in the upgrade template configuration file.
Perform the ISO upgrade procedure.
This step details the procedure to perform an ISO upgrade on the EMS primary server.
This step shows the post-upgrade mandatory tasks, after EMS upgrade is successful.
The EMS Secondary server is first upgraded followed by EMS Primary server. If the value set for _ems_bac
kup is true then backup is taken prior to upgrade on the EMS Primary server at the path /opt/oracle/
backup/dmp. In case the upgrade on secondary EMS fails, the upgrade process exits. The EMS Primary
server provides continued service without any downtime. Restore the backup files stored at the path /opt/
oracle/backup/dmp on the secondary server and retry the upgrade procedure.
If EMS HA Upgrade fails and both the primary and secondary servers are unstable, you can perform a fresh
EMS installation and restore the backup taken earlier. For more information, on how to kickstart EMS and
restore previous stable configuration refer Rollback EMS HA .
The EMS Upgrade Configuration File
The ems_upgrade.conf file is auto-generated and is used while upgrading EMS. The ems_upgrade.conf file
has a list of properties, which primarily designate backup and upgrade related parameters. Based on your
requirement, you can edit the properties defined in the ems_upgrade.conf file using the vi editor. The following
table provides usage and significance of each property in the ems_upgrade.conf file.
If _ems_backup is set to ‘false’, database backup is not generated. Sonus recommends to retain the _em
s_backup default value to ‘true’ so that Database backup is taken and DB can be restored, if the upgrade
fails. The backup files are generated at the path /opt/oracle/backup/dmp on the EMS primary server.

Property Name Default Usage
Value
_ems_backup true Indicates whether you want to take the backup of EMS database and
configuration. The default value is true, however, if you do not want to take
backup, change the value of _ems_backup to false.
_ems_pmstats_table_backup true Indicates, if backup of PM stats tables is required or not. Change it to false, if
backup of PM Stats table is not required.
Upgrading EMS HA Configuration Using ISO Image

This section provides information on upgrading EMS HA system using the ISO file. It covers the following
sections:
Upgrade Procedure
Increasing ASM Partition Size (Optional)
Upgrade Procedure
Total time for upgrading both the primary and secondary servers using ISO upgrade is approximately 40 to
45 minutes.
The following steps are executed only on the EMS Primary Server that is Active. To upgrade the EMS HA using an
ISO file, perform the following steps:
Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700
1. Log in as a root user to the Insight EMS Primary server that is Active.
2. Change the directory to the path where the
emsrac-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso and upgradeEMS.sh files have been
copied.
3. After downloading the file upgradeEMS.sh, login as ‘root’ user and change the permission of
upgradeEMS.sh using the following command:

# ./upgradeEMS.sh -p [Absolute Path of the ISO file]
The standby server is first upgraded and rebooted and then the active server is upgraded.
a. After reboot, when the primary server is up, login as root user and verify that EMS has been
upgraded to version 9.3.x, by executing the following command:
# rpm -qa SONSems

SONSems-V09.03.00-R000.x86_64
b. On the secondary server, verify that the EMS software has been upgraded to 9.3.x, by executing the
following command:
# rpm -qa SONSems

SONSems-V09.03.00-R000.x86_64
After the upgrade is performed successfully on both the primary and secondary servers, the
original active server would be standby and the original standby server would be active. To
revert to the original state, execute the command /opt/sonus/ems/conf/HA/RAC/sonu
sEMS relocate.
The above procedure completes the default upgrade process for both the active and standby servers
for a EMS HA deployment.

a.

file]

# Configuration template for EMS RAC upgrade

# You may edit this file before upgrade
#
# Change the value to "false", if the backup is not required.
_ems_backup=true

7. After you have generated and updated the ems_upgrade.conf file, execute the following command:

[Absolute path of the EMS HA ISO File]
information, see Rollback EMS HA.
8. After reboot, when the primary server is up, login as root user and verify that EMS has been upgraded to
version 9.3.x, by executing the following command:
# rpm -qa SONSems

SONSems-V09.03.00-R000.x86_64
9. On the secondary server, verify that the EMS software has been upgraded to 9.3.x, by executing the following
command:

9.
# rpm -qa SONSems

SONSems-V09.03.00-R000.x86_64
10. Perform the following steps to verify if database and kernel have been updated:
06.04.02.00R000
# uname -r
2.6.32-504.3.3.el6.x86_64
$ sqlplus -version

version:
(19271438)"
After the upgrade is performed successfully on both the primary and secondary servers, the original
active server would be standby and the original standby server would be active. To revert to the
original state, execute the command /opt/sonus/ems/conf/HA/RAC/sonusEMS relocate.
The above procedure completes the upgrade process using the upgrade configuration file for both the active

and standby servers for a EMS HA deployment.
Increasing ASM Partition Size (Optional)
In case, the database size is not sufficient, you can increase the DB size using the ASM Partition mechanism.
Increasing the ASM partition size is an optional procedure and increasing the DB size is dependent on insufficient
DB space.
Increasing ASM Partition Size is optional and is applicable only for IBM DS3524 RAID. To check the ASM
Partition free space, execute the command:
# fdisk -l /dev/mapper/asm_device
Caution
If you have sufficient DB space available, there is no need to execute the ./ASMPartition script.
If you do not have sufficient DB space, you can increase the DB size, by executing the following
1. Log in as root user to the Active Server.

2. Change the directory to /export/home/pkg
3. Assign the privilege to execute the ./ASMPartition script on both the active and standby server, using the
following command:
# chmod +x ASMPartition
4. Execute the ./ASMPartition command on the active server to increase the DB size. Execute the
command ./ASMPartition from the active server.
# ./ASMPartition
Executing the ./ASMPartition script, takes substantial time to complete. Please wait for the
script to complete execution. Executing the ./ASMPartition command automatically reboots both
the servers.

After the ./ASMPartition script completes the execution, the original active server would be
standby and the original standby server would be active. To revert to the original state, execute the
command /opt/sonus/ems/conf/HA/RAC/sonusEMS relocate

Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700
The following summary outlines the key steps required to upgrading EMS application for EMS HA DR configuration.
Download and prepare the upgrade files on the source and target EMS HA systems.
Manual Backup EMS Data on the source and target EMS HA systems.
This step is used to manually backup EMS database and configuration.
a. Perform INPLACE ISO upgrade procedure on the DR source primary EMS system.
b. After completing the DR Source site upgrade, perform INPLACE ISO upgrade procedure on the DR
target primary EMS system.
If EMS HA upgrade fails at the source DR site, you must manually perform a
failover at Target DR site to function as the new source for DR site. Execute the
command 'manageDR failover' on the active system of Target site, to
perform failover and allow Target to function as the new Source of DR site. For
more details about failover, refer the section Failover.
Perform the mandatory post-upgrade tasks on the source and target EMS HA systems.
This step shows the post-upgrade mandatory tasks that need to be performed after EMS upgrade is successful.

restore previous stable configuration refer Rollback EMS HA.
Post-Upgrade Steps

For password related information, refer the section Managing Insight Account Names and Passwords".
You need to select an NTP server for your network. The installation process requires only one NTP server.
However, it is recommended that you add a second NTP server after you complete the installation process. The
second server acts as a backup server, in case the primary NTP server goes down.
You must add a second NTP server only after the installation is complete.
Perform the following procedure to add a second NTP server:

2. Using the vi editor, edit /etc/ntp.conf file and add the second server IP address.
server <ntp_server_ip_address / hostname>
For example:
# server 127.127.1.0
3. Enter the following command to restart the ntp server.
# /sbin/service ntpd restart

Starting NTP service .................................................... Fri
May 31 20:40:53 IST 2013
Starting ntpd: [ OK ]
(ok)


wards.

PSX V09.03.00R000

server:
# su - insight

system.

# ./GuiClient.sh
SONSems-V09.03.00-R000.x86_64
SONSpsx-V09.02.00-R000.x86_64

Removing SONSpsx.
Installing SONSpsx.
Preparing... ########################################### [100%]
1:SONSpsx ########################################### [100%]

PSX V09.03.00R000

16. Start EMS on the primary and secondary server as user insight, by executing the following command on EMS
Primary system:
# su - insight
20.


do the following:

If the HP Firmware version is the not the latest then upgrade the HP Firmware to the latest version,
by performing the following steps.
4. Upgrade HP Firmware on non-primary (automatically reboots). For upgrading firmware, refer HP DL380p G8
Firmware Upgrade.
5. Relocate EMS (making non-primary active).
6. As user root, enter the following command on the primary server, which is active:
7. Upgrade HP Firmware on primary (automatically reboots). For upgrading firmware, refer HP DL380p G8
Firmware Upgrade.
8. Relocate EMS by making primary as active.
9. As user root, enter the following command on the non-primary server, which is active:
The primary server again becomes the active server.

10. The above procedure completes the upgrade firmware for HA setup.
If you are upgrading EMS SWe for KVM or VMware ESXi, upgrading IBM V3700 RAID firmware is not
required. Upgrading IBM V3700 firmware is applicable only for EMS HA physical server-based upgrade.
Verify if the IBM V3700 firmware is the latest version. For IBM V3700 Firmware latest version and procedure to
upgrade the Firmware, refer the page IBM Storwize V3700 Firmware Upgrade Quick Start.

Upgrading EMS to V09.03.00 removes the previous device manager (DM) on the system, if it was installed earlier.
After upgrading EMS 9.3.0, install the respective DM supported for EMS 9.3.0. For more information on Device
Manager, see the SBC Manager section of the Insight User Guide. For more information on installing or upgrading
Device Manager, refer Installing and Upgrading Device Manager (DM).
Rollback EMS HA
Reverting the EMS HA to previous version
1. Install Insight using the old ISO on both the EMS HA systems (active and standby) by performing the
following:
For EMA HA deployed for DR setup, perform the following steps on source and target DR sites.
a. Perform Insight Installation using the old ISO. see "Kickstart the HP G8 Servers ".
b. Configure RAID and Install Oracle Clusterware.
c. Perform "Post-Installation Steps".
d. Enter the following command on Primary server to start Insight as user insight:

exp_data_manual.dmp
3. Run the following command as root user on EMS Primary server:
4. Enter the following command on EMS Primary server to migrate the data:


log

For EMS HA deployed for DR setup, after rollback of previous data is completed on source and
target DR sites, setup DR by executing the command ./manageDR setup on the active system at
This section provides information on migrating EMS HA on Solaris or pre-EMS 9.1 HA on Linux to the new EMS HA
solution.
For details on migrating the existing EMS HA licenses, refer to License Considerations for Hardware
Migration.
Links to other pages:


This section provides information on migrating the pre-EMS 9.1 HA Linux configuration to the latest HA Linux
configuration.
Perform the following tasks:
Exporting Data from Pre-EMS 9.1 HA System

Importing Data to the New HA System
Post-Migration Tasks
Exporting Data from Pre-EMS 9.1 HA System
This section provides information on exporting the data from the pre-EMS 9.1 HA Linux.
Prerequisites
The prerequisites to export data from an pre-EMS 9.1 HA Linux system, are as follows:
The Linux HA servers (Primary and non-primary) must be up and running.

Download the migrationExport.sh script file from Salesforce available under WL9.3 Software Bundle
and copy it to the primary EMS system.
Procedure for Exporting Data from Pre-EMS 9.1 Primary server

Perform the following procedure to export data from the pre-EMS 9.1 HA Linux primary server:
1. Login as root on pre-EMS 9.1 HA Linux primary server from where you want to export the data.
step is executed.
2. Ensure that you are in the directory where you have copied the migration script. The backup directory must
have the migrationExport.sh script available. Execute the following command on the primary pre-EMS
9.1 server to export the data.
# ./migrationExport.sh
This script will take a DB Backup for Migration.

Running DB Backup Script. Please tail
/var/ems/migrateExport.log to monitor progress.
...
...<Command Output cut for brevity>...
...
/bin/tar: Removing leading `/' from member names
/var/ems/migrateExport.log has been included
in the backupFiles.tar tar for future reference.
The above procedure completes generating the backup of database (DB).


Importing Data to the New HA System
This section provides information on importing the data from the pre-EMS 9.1 HA system to the new HA system.
Prerequisites
For prerequisites to import data on Linux, refer the section Installing Insight HA on Linux.
After completing the above mentioned prerequisites, you can proceed with Importing Data on Primary Serve
r
Importing Data on Primary Server

1. Perform the following step on the primary Linux server (also known as node 1 of HA).
a. Copy the following files from the pre-EMS 9.1 Linux primary server to the New EMS Linux Primary
server at the path /export/home/backups/
If the dmp files are copied to /export/home/backups using an unconventional method,

such as FTP, change the owner and group of the files to Oracle and DBA.
# cd /export/home/backups
or
3. Enter the following command on the new primary Linux HA server to migrate the data:
The following output appears:

The logs for the migration procedure is available at /var/sadm/install/logs/EMSmigration*

.log.
After importing the data, you need to perform the following post-migration tasks:
Associating the Node

Discovering SGX-4000 device (if configured)
Disassociating the Node
Update all the existing nodes to point to the EMS HA cluster new shared IP address (VIP). To update all the existing
nodes, perform the following steps:

2. Enter the EMS HA cluster VIP in the IP Address field as shown below.


4. Click OK.

If SGX4000 device is configured, you have to perform the following procedure during data migration.
a. -SSH Port
b. -Login (CLI)
c. -Password (CLI)
Disassociate all of the nodes with the pre-EMS 9.1 HA IP address to avoid traps being sent from the nodes to the
old EMS IP address. Perform the following steps to disassociate all of the nodes:
3. Enter the pre-EMS 9.1 HA IP in the IP Address field as shown below.


5. Click OK.
successfully disassociated. You need to perform a manual configuration to remove the pre-EMS 9.1 HA IP
address as the trap destination.
the migration)

This section provides information on migrating from Solaris HA on Netra 5220 or Netra 240/440 system to EMS 9.3
Linux HA.
Exporting Data from Solaris to Linux

Importing EMS Data to the EMS HA Linux System
Exporting Data from Solaris to Linux
This section provides information on exporting data from EMS HA Solaris system.
Prerequisites
The prerequisites to export data from Solaris system, are as follows:
The Solaris Netra 5220 or Netra 240/440 (Primary and non-primary) servers must be up and running.
Download the migrationExport.sh script and EmsSolarisMigration.tar file from Salesforce
available under WL9.3 Software Bundle and copy it to the Primary EMS System.

The migrationExport.sh script is used for backing up the EMS data from the Solaris system and this
script automatically performs the following tasks:
Netcool Installation
Exporting Netcool Data
Database (DB) backup
Procedure for exporting Data from Solaris Primary server
Perform the following procedure to perform OMNIBus Installation and export data from the Solaris system:
1. Login as root user on Solaris primary server.

Ensure that you are in the directory where you have copied the migration script. Both the files
migrationExport.sh script and EmsSolarisMigration.tar are available in this directory on the
Solaris primary server.
step is executed.
Execute the following command on the Solaris primary System to install OMNIBus and export data from
Solaris HA to Linux HA servers.

# ./migrationExport.sh -p EmsSolarisMigration.tar
This script does the following:
-->Netcool OMNIBus 7.3.1 Installation

-->Netcool OMNIBus 7.3.1 Fix 1 Installation
-->Exporting NetcoolData
-->DB Backup
Extracting EmsSolarisMigration.tar . . .
Checking for availability of the files required for performing migration . . .
Check completed.
. . . . .
Netcool OMNIBus 7.3.1 has been installed successfully !!
Extracting 7.3.1-TIV-NCOMNIbus-solaris2-FP0001.tar . . .
Please tail /var/ems/migrateExport.log to track progress.
Installing Netcool OMNIBus 7.3.1 Fix 1 . . .
Netcool OMNIBus 7.3.1 Fix 1 has been installed successfully !!
. . . . .
. . . . .
. . . . .
Export: Release 11.2.0.3.0 - Production on Fri Apr 11 04:03:05 2014
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 -
64bit Production
Export done in UTF8 character set and AL16UTF16 NCHAR character set
Note: grants on tables/views/sequences/roles will not be exported
Note: indexes on tables will not be exported
Note: constraints on tables will not be exported
. exporting pre-schema procedural objects and actions
. exporting foreign function library names for user DBIMPL
. . . .
. . . .
/var/ems/migrateExport.log has been included in the backupFiles.tar tar for
future reference.
The above procedure completes Netcool installation, exporting netcool data, and database (DB) backup.

Importing EMS Data to the EMS HA Linux System
This section provides information on importing the EMS data to the EMS HA Linux system.
Prerequisites
For prerequisites to import data on Linux, refer the section Installing Insight HA on Linux.
Importing Data on Primary Server

1. Perform the following step on the primary Linux server (also known as node 1 of HA).
a. Copy the following files from the Insight system on Solaris to the current location
/export/home/backups on Linux primary system.

If the dmp files are copied to /export/home/backups using an unconventional method,
or
# cd /export/home/pkg/
3. Enter the following command on Primary Linux server to migrate the data:
If Proxy Preferred IP address is configured in old EMS Solaris and if it is different from EMS IP
address, then you will be prompted to enter a new value for the Proxy Preferred IP address while
migrating to EMS Linux.
# ./EMSmigration -b /export/home/backups/

The logs for the migration procedure is available at /var/sadm/install/logs/EMSmigration*

.log.

After importing the data, you need to perform the following post-migration tasks:

Update all the existing nodes to point to the EMS HA cluster new shared IP address (VIP). To update all the existing
nodes, perform the following steps:

2. Enter the EMS HA cluster VIP in the IP Address field as shown below.

4. Click OK.

If SGX4000 device is configured, you have to perform the following procedure during data migration.
a. -SSH Port
b. -Login (CLI)
c. -Password (CLI)
Disassociate all of the nodes with the old EMS IP address to avoid traps being sent from the nodes to the old EMS
IP address. Perform the following steps to disassociate all of the nodes:
3. Enter the old EMS IP in the IP Address field as shown below.


4.
5. Click OK.
successfully disassociated. You need to perform a manual configuration to remove the old IP address as the
trap destination.
the migration)
The IBM V3700 RAID is supported on Linux platform with EMS application installed on a HP G8 system. This
section provides details about how to migrate data from StorageTek RAID or IBM DS3524 RAID to IBM V3700
RAID. It contains the following topics:
Migrating Data from Sun Solaris with StorageTek RAID or IBM DS3524 to HP G8 on Linux with IBM V3700
RAID
Migrating Data from Sun Solaris with StorageTek RAID or IBM DS3524 to HP
G8 on Linux with IBM V3700 RAID
The procedure to migrate data from Sun Solaris with StorageTek RAID or IBM DS3524 to HP G8 on Linux with IBM
V3700 RAID, is same as Migrating data from Solaris to Linux. For more information, refer the procedure Migrating
from Solaris to Linux.
Migrating from IBM DS3524 RAID (HP G8 System on Linux) to IBM V3700

RAID
This section provides information on migrating from EMS HA Linux with IBM DS 3524 to EMS HA Linux with IBM
V3700 RAID.
Exporting Data from EMS HA with IBM DS 3524 RAID

Importing Data on IBM V3700 RAID
Exporting Data from EMS HA with IBM DS 3524 RAID
This section provides information on exporting data from EMS HA connected to IBM DS 3524 RAID to EMS HA
connected to IBM V3700 RAID.
Prerequisites for Exporting Data from IBM DS3524 RAID (HP G8 System on Linux)
For prerequisites to export data from IBM DS3524, refer the Prerequisites section.
Procedure for exporting data from EMS HA with IBM DS 3524 RAID
Perform the following steps to export data:
Export data from IBM DS3524 RAID, by performing the steps given in Procedure for Exporting Data from
Pre-EMS 9.1 Primary server section.
After exporting the data, move the backup files generated to a remote system.
When exporting data from an EMS HA with IBM DS 3524 RAID, the following files are generated.

This section provides information on importing the data on EMS HA Server connected to IBM V3700 RAID.
Prerequisites for Importing Data on IBM V3700 RAID
As IBM V3700 RAID is supported only on Linux platform with HP G8 systems, you need to perform the following
steps, before importing the data to IBM V3700 RAID.
1. Replace the IBM DS3524 RAID with IBM V3700 RAID. For more details about V3700 hardware and software
requirements, refer Prerequisites. For setting-up IBM V3700 RAID, refer EMS HA Cluster Cabling and
Network Connectivity.
2. Kickstart both the HP G8 systems (primary and secondary) with ISO. For more details regarding kickstarting
the HP G8 system, refer Kickstart the HP G8 Servers.
3. Copy the backup files mentioned in above Table from remote system to EMS Linux Primary system.
4. After completing the above mentioned prerequisites, you can proceed with Importing Data on IBM V3700
RAID
Import Data on IBM V3700 RAID, connected to HP G8 systems, by performing steps as mentioned in the section
Importing Data on Primary Server.
After importing the data, you need to perform the following post-migration tasks if you have configured SGX-4000:

This page contains information pertaining to the troubleshooting related procedures.
RPM Corruption
This section provides the troubleshooting procedure of the following scenario. When the rpm command is executed,
lot of errors are seen due to which the EMS HA status is not visible.
Perform the following procedure for troubleshooting:

2. Execute the following command:
# rm -rf /var/lib/rpm/__db.00*

# rpm --rebuilddb

Table of Contents
Uninstalling IAS
Overview
The Insight Application Server (IAS) is a separate node running any or all of the following (depending upon
licensing):
Insight EMS API

Insight SMS API
Insight SGX API
Lawful Intercept Provisioning
Heavy use of the of both the SMS and EMS APIs in particular can place significant load on Insight. Off-loading or
distributing API processing with an IAS node can allow Insight to scale and meet the requirements of networks with
substantial API needs.
Deployment of one of more IAS nodes provides the following advantages:
allows you to offload API provisioning tasks from the Insight EMS server.
allows for uninterrupted API provisioning in cases where the Insight server is offline (for example, during an
upgrade)

provides greater scalability
Additionally, the user has the option to off-load the GSX and PSX CLI to the IAS. To enable this, the EMSCLI
license is applied to the IAS. For more information about IAS, see Insight User Guide.
This section provides details for installing and upgrading an Insight Application Server (IAS).
You require two servers to install Insight Standalone (SA) and IAS. You need to install Insight on server A
before installing IAS on server B.
Three servers are required to install Insight High-Availability (HA) and IAS. You need to install Insight HA on
servers A and B before installing IAS on server C.
Prerequisites
The following are the prerequisites for installing an IAS:
Know the IP address of the remote system on which you want to install IAS.
Know the password for the root user on the remote system.
Ensure root ssh login is permitted on the remote system.
Have a system that meets the hardware requirements. For more information on the hardware and software
requirements, see Hardware Requirements and Network Connectivity Information and Server Configurations
Sonus recommends you to start Insight on the EMS before you install the IAS.
Ensure the system BIOS date is current date.
Navigation
The mouse cannot be used for navigation. When a list of choices are displayed, use the UP or DOWN arrow key to
highlight your choice and press ENTER to mark your selection.
Perform the following steps to prepare the IAS System for ISO image installation:
You need to configure the RAID hardware before you install using the ISO image. For more details, see Co
nfiguring the RAID Hardware.
1. Open a web browser and type the IP address to access the iLO. The login screen appears.
Enter the iLO login name and password.
2. Mount the virtual disk as CD-ROM by selecting Virtual Drives and check the Image File.

Figure 69: Selecting Image File
3. Browse to the location where you have stored the ISO image and select the ISO image and then click the
Open button.
4. Connect the monitor and keyboard to the server or launch the Remote Console from iLO.
For launching Remote Console, see Launching the iLO Remote Console.
5. Reboot the server.
The HP BIOS execution window appears.
Figure 70: HP Proliant Screen
6. Press F11.
The F11 icon is highlighted on the screen and the Default Boot Override Options appear.

6.
Figure 71: Default Boot Override Options
7. Type 1 and press ENTER.

The Installer screen appears.
Figure 72: Installation Selection
8. Type 2 and press ENTER to install IAS.
9. The following screen appears.

10. After a few minutes, the following screen appears and you can view the various RPM packages getting
installed.

30 minutes.
11. After successful installation of Red Hat Enterprise Linux, the following screen is displayed. Use the Tab key
to select Reboot button. After selecting Reboot button, press Space key to reboot the system.

12. After the system is rebooted, the following screen is displayed. Press F1 to continue.
Figure 77: F1 Key to Continue
13. When the system comes-up, you need to perform the network configuration. As part of Network
Configuration, you need to configure the Hostname, IP address for network interfaces, Time Zone, and Time
Server.
Select Hostname and press Space key configure the hostname for the system.


b.
IP Address details.

d. Use the Arrow keys to select Time Zone and press Space key to configure the Time Zone. Select the
Zone settings.
Figure 82: Timezone
e. Enter the NTP Time-Server IP Address, to synchronize the time for the VM host system.

e.
Figure 83: NTP Time-Server Configuration Screen
Login screen is displayed, after the IAS Application Software is successfully installed.

15. Unmount the virtual disk as CD ROM by selecting Virtual Drives from the menu and un-check the Image
File check box.
16. Press F9 to change the setup.

Figure 84: ROM Based Setup
17. Select the Standard Boot Order (IPL) option and press ENTER.
The boot order appears.

Figure 86: Choosing boot order
Figure 87: Updated Boot Order Screen
20. Press ESC.


Figure 88: Configuration Utility
23. The Red Hat Enterprise Linux Server installation screen is displayed.
24. After completing the installation, the following message appears:
IAS Preparation is complete
25. Reboot the system.

26. Change the default password. For more information, see Changing the Password.
27. Install IAS. For more information about installing IAS, see IAS Remote Install Procedure.
Perform the following procedure to install the IAS software:
This procedure is not applicable to install IAS remotely from Linux to Solaris IAS.
1. On the Insight server, begin the IAS installation script:
# cd /opt/sonus/ems/conf/IAS
# sh remoteIasInstall.sh <ias_ip_address>
where <ias_ip_address> is the IP address of the remote system on which you want to install IAS.

2. When prompted, enter the password of the root user for the remote system.
Messages appear that state that remote information is being retrieved and installation files are being copied
to the remote system. When the IAS is ready to be installed, a message appears that this may take several
minutes.
A message then appears stating that the IAS installation completed successfully, and that the IAS has
started.
Perform the following procedures to start and stop the IAS.
Starting an IAS Server
To start an IAS server, Insight must first be running on the Insight EMS server. You can then start the IAS by logging
into the Insight EMS server as user insight and entering the following:
$ cd /opt/sonus/ems/conf/IAS
$ ./remoteIasMgmt.sh start <ias_ip_address>
where <ias_ip_address> is the IP Address of the IAS, which can either be an IPv4 or an IPv6 address type. The
script prompts you for the insight user password of the IAS system and then proceeds with the command. Once the
IAS is started, it will continue to run even if Insight is stopped.
Stopping an IAS Server
To stop an IAS server, Log on to the Insight EMS server as either root or insight and enter the following:
# ./remoteIasMgmt.sh stop <ias_ip_address>
where <ias_ip_address> is the IP Address of the IAS. The script prompts you for the root or insight user
password of the IAS system and then proceed with the command.
To start an IAS server, Insight must first be running on the Insight EMS server.
1. You can then start the IAS by logging into the Insight EMS server as user insight and entering the following
command:
$ ./remoteIasMgmt.sh start <client_ip_address>
where <client_ip_address> is the IP address of the IAS. The script prompts you for the insight user

password of the IAS system and then proceeds with the command. Once the IAS is started, it will continue to
run even if Insight is stopped.
1. To stop an IAS server, log on to the Insight EMS server as either root or insight and enter the following:
# ./remoteIasMgmt.sh stop <client_ip_address>
where <client_ip_address> is the IP Address of the IAS. The script prompts you for the root or insight
user password of the IAS system and then proceeds with the command.
To obtain the status of an IAS server, log on to the Insight EMS server as either root or insight and do the following:
# ./remoteIasMgmt.sh status <client_ip_address>
where <client_ip_address> is the IP address of the IAS. The script prompts you for the root or insight user
password of the IAS system and then proceeds with the command. The output of the status command looks similar
to the following:
Retrieving version information from the 10.54.159.32 as root.

The version information for 10.54.159.32:
Curr IAS version: V09.02.00
Prev IAS version:
Curr Agent version: V09.02.00
Prev Agent version:
Curr JBoss version: 5.1.0-GA09.00.00R000
Prev JBoss version:
Curr JRE version: 1.7.0-09_icedtea
Prev JRE version:
Curr Axis version: 1.2.1
The IAS server on 10.54.159.32 is running.
When the changeIpAddress.sh script is used to change the IP address of the Insight server, all IASs that are
registered to the Insight server should be automatically updated to the new IP address of the Insight server.
If you need to manually update the Insight IP address that is on an IAS, use either of the following methods:
Updating the Insight IPv4/IPv6 Address on a specific IAS

Updating the Insight IPv4/IPv6 Address on all IASs
Updating the Insight IPv4/IPv6 Address on a specific IAS

To update the Insight IPv4/IPv6 address on a specific IAS, perform the following steps:
1. Login as root user on the Insight server.

# ./remoteIasMgmt.sh resetInsightIP <client_ip_address>
where <client_ip_address> is the IPv4/IPv6 address of the IAS on which you want to update the Insight
IPv4/IPv6 address.
The Insight IPv4/IPv6 address on the IAS is updated to the IPv4/IPv6 address of the Insight server.
The IAS system can prompt to enter root password.
Updating the Insight IPv4/IPv6 Address on all IASs

To update the Insight IPv4/IPv6 address on all the IASs that are registered to the Insight server, perform the
following:
1. Login as root user on the Insight server.

# ./resetInsightIPForAll.sh
The Insight IPv4/IPv6 address on all IASs that are registered to the Insight server are updated to the
IPv4/IPv6 address of the Insight server.
The system prompts you to enter root password on each of the registered IASs.
If you have the system administrator change the name or the IPv4/IPv6 address of the IAS, you do not have to
change any additional files. You do need to Update the IAS node in the Insight Node Registration Page, and
rediscover the IAS node. See “Updating a Node” in the Insight Administration chapter of the Insight EMS User
Guide.
If you install the Insight API, Insight SMS API, Insight SGX API, or Lawful Intercept Target Provisioning API on an
IAS, you must purchase a license for each instance of an API module you want to use. You cannot share a license
between an API module on the Insight server and an API module on an IAS. For example, you cannot share a single
license between an Insight SMS API module on the Insight server and an Insight SMS API module that is installed
on a remote system with IAS.
Enabling HTTP access on IAS server
Perform the following procedure to enable HTTP access on IAS server:

1. To enable HTTP access on IAS server, execute the following command
# cd <IAS_BASE>/bin
# ./enableHTTP.sh
Enabling HTTP access to IAS server

The script will now proceed with enabling HTTP for client access.
The IAS server will be stopped now. Do you want to proceed? (default: yes)
[y,n] y
Stopping IAS...
*** Stopping IAS! - Thu Apr 25 12:55:05 IST 2013 ***
IAS Server stopped.
Stopping Sonus NEAP RMI server.
The Sonus NEAP RMI server has been stopped.

Modifying /opt/sonus/ias/server/deploy/jbossweb.sar/server.xml
Completed changing protocol to http. Please restart the IAS server.
Disabling HTTP access on IAS server
Perform the following procedure to disable HTTP access on IAS server:
1. To disable HTTP access on IAS server, execute the following command
# cd <IAS_BASE>/bin
# ./disableHTTP.sh
Disabling HTTP access to IAS server

The script will now proceed with disabling HTTP for client access.
[y,n] y
Stopping IAS...
IAS Server stopped.

Modifying /opt/sonus/ias/server/deploy/jbossweb.sar/server.xml
Completed changing protocol to https. Please restart the IAS server.
IAS Upgrade Procedure

Use the following procedure to upgrade the IAS software.
1. On the Insight server, execute the remoteIasInstall.sh script:
# sh remoteIasInstall.sh <client_ip_address>
where <client_ip_address> is the IP address of the remote system on which you want to upgrade IAS.
3. Messages appear that state that remote information is being retrieved, and upgrade files are being copied to
the remote system.
4. When the IAS is ready for upgrade, a message appears that this may take several minutes.
started.
The remoteIasInstall.sh script takes care of both IAS install and upgrade.
where <client_ip_address> is the IP Address of the IAS, which can either be an IPv4 or an IPv6 address type.
The script prompts you for the insight user password of the IAS system and then proceeds with the command. Once
the IAS is started, it will continue to run even if Insight is stopped.
where <client_ip_address> is the IP Address of the IAS. The script prompts you for the root or insight user

File to be Downloaded
The following table provides file to be downloaded for HP Firmware upgrade.
Firmware File
Firmware file
Firmware Upgrade
Uninstalling IAS
Perform the following procedure to uninstall IAS on HP DL380p G8 remotely:
1. If you are uninstalling IAS on HP DL380p G8, the procedure may approximately take 30 minutes.
# sh remoteIasUnInstall.sh <client_ip_address>
where <client_ip_address> is the IP address of the remote system on which you want to install IAS.
4. Enter y to confirm uninstallation.
Are you sure you want to uninstall the IAS server on 10.54.2.83? [y,n,q]
(default: n):
The process on IAS and Sonus Agent are stopped. A message then appears stating that the IAS is
uninstalled completely.

Table of Contents

Configuring IPv6
This section contains mandatory and optional post-installation/upgrade tasks. The mandatory tasks must be
performed to complete the Insight installation.
Table 26: Post-installation or Upgrade Tasks
Task Description Optional or Mandatory
Clearing Client Java Cache After a Perform this task on each client after an Insight Optional
Software Upgrade installation.
Enabling SSH Perform this task after ISO installation if you are Mandatory
using SSH for communication between the Insight
server and the PSX, SGX, and DSI.
Licenses for Enabling Insight API, Contact your Sonus representative to obtain software Mandatory
Insight CLI, SMS API, SGX API, licenses.
Lawful Intercept Provisioning API,
and Traffic Manager This task
is
mandatory
only when
you are
using
licensable
features
Enabling Mailx Perform this task to enable mailx. Optional
User Account Lock Settings Perform this task to unlock an account and configure Optional
the settings for user account and password.
Synchronizing with the NTP Server Perform this task after ISO installation. Optional
Online Library Installation Perform this task to install the documentation. Optional
SSL Certificate Installation Perform this task after an Insight installation if you Optional
Procedures need to support HTTPS in a production environment.
Enabling Users to Create Cron Jobs Perform this task after ISO installation if you need to Optional
allow users to create cron jobs.
Enabling Users to Create at Jobs Perform this task after ISO installation if you need to Optional
allow users to create at jobs.

Configuring Multiple Network Perform this task after an installation if the Insight Optional
Interfaces server uses multiple network interfaces.
Managing IP Bonding for a non-HA Perform this task for non-HA systems after an Optional
System installation if the Insight server uses bonding. This is
recommended by Sonus to protect the EMS from a
single-switch failure.
Clearing the Core Files Perform the task to clean up the unwanted cores Optional
periodically.
Limiting Maximum Login Sessions Perform this task to limit the login sessions for a user. Optional
Unlocking the Locked User Account Perform this task to unlock an account. Optional
Modifying user session time-out Perform the task to modify the time-out interval. Optional
interval
Password Perform the task to modify password aging days, Optional

restricting a user to change password during first
login, and change a password.
Setting Permissions Perform the task to add setuid permission on Linux Optional
commands.
Changing the GRUB Password Perform the task to change grub password. Optional
Deploying LNP Adaptor Perform the task to deploy LNP Adaptor. Optional
Enabling or Disabling HTTP access Perform the task to enable and disable HTTP access Optional
on the EMS Standalone Server to EMS server.
Changing Timezone and Network Perform the task to change time zone or network Optional
Configuration configurations.
Common Post Installation or Upgrade Tasks for SA and HA

The post-installation or post-upgrade tasks to be performed for Standalone (SA) or High-Availability (HA)
modes are:
Clearing Client Java Cache After a Software Upgrade

Enabling SSH
Licenses for Enabling Insight API, Insight CLI, SMS API, SGX API, Lawful Intercept Provisioning
API, and Traffic Manager
Enabling Mailx
User Account Lock Settings
Synchronizing with the NTP Server
Online Library Installation
Enabling Users to Create Cron Jobs
Enabling Users to Create at Jobs
Clearing the Core Files
Limiting Maximum Login Sessions
Unlocking the Locked User Account
Modifying user session time-out interval
Password
Setting Permissions
Changing the GRUB Password
Deploying LNP Adaptor
Changing Timezone and Network Configuration
Clearing Client Java Cache After a Software Upgrade
After you perform an upgrade to a new version of Insight software, have each user who is running an Insight client
clear their Java cache to prevent cached pages from the previous version from being temporarily displayed.
Perform the following procedure to clear the Java cache:
1. From the Start menu, select Control Panel.

The Control Panel appears.
2. Select Java.
The Java Control Panel appears.
3. From the Java Control Panel, select the General tab.
4. From the Temporary Internet Files, click Settings.
The Temporary File Settings dialog appears.
5. Click Delete Files.
The Delete Files and Applications dialog appears.
6. Select Trace and Log Files check-box, to delete trace and log files.
7. Select Cached Applications and Applets check-box, to delete applications and applets.
The Installed Applications and Applets check-box need not be selected.
8. Click Ok to save the changes.

The Java cache is cleared.

Enabling SSH
SSH is installed during the installation of Redhat Linux 6.4.2, but it must be enabled in order to use it. If you want to
use SSH for communication between the Insight server and the PSX, SGX, and DSI servers, you must enable SSH
on the Insight server and on the PSX, SGX, and DSI servers. This version of SSH includes the following
components: SSH Server, SSH client, Secure FTP (SFTP), and Secure File Copy.
Enabling SSH on Server
Perform the following procedure to enable SSH on a server:
1. As a user with root privileges, change to the SSH server configuration directory:
# cd /etc/ssh
2. Make a backup of the SSH server (SSH daemon) configuration file:
# cp sshd_config sshd_config.backup
3. In the sshd_config file, make the following changes:

Change:
AllowTcpForwarding no
to
AllowTcpForwarding yes
Change:
PermitRootLogin no
to
PermitRootLogin yes
4. Save and close the sshd_config file.

5. Enter the following command to restart SSH:
# service sshd restart
6. Verify that SSH has been started:
# service sshd status
The system displays the following:

openssh-daemon (pid 2556) is running...
Enabling SSH on Nonstandard Port
Perform the following procedure to enable SSH on a nonstandard port:
1. Login as root user and go to the following directory:
# cd /etc/ssh
2. Backup the SSH server (SSH daemon) configuration file:
3. Edit the sshd_config file to change the nonstandard port number:

Change:
#Port 22
to:
Port 2024

# service sshd status
openssh-daemon (pid 2556) is running...
Enabling Key Based Authentication for SSH
After completing this procedure, you can login using target user account on a target machine from a host machine

without any password. The following is the explanation of the terms used in the procedure:
Host Machine: This machine is used to logon to the Target machine.

Host User: The user on host machine which is used to login to host machine.
Target Machine: Logon to this machine from another machine.
Target User: User on the target machine one wants to log into.
Perform the following procedure to enable key based authentication for SSH:
1. Log onto the host user account on the host machine using SSH.
2. Change the directory to host user ssh directory:
$ cd .ssh
3. Check if id_rsa and id_rsa.pub exists by executing the following command:
$ ls
If id_rsa and id_rsa.pub files exists, go to step 6.

4. Execute ssh-keygen to generate the public or private RSA key pair:
$ ssh-keygen -t rsa
5. Press ENTER to save key files or pass phrase.

The ssh-keygen utility generates private key file as id_rsa and public key file as id_rsa.pub.
6. Copy id_rsa.pub file to <hostname>.pub file:
$ cp id_rsa.pub <hostname>.pub
For example, if the hostname is jupiter, then enter the following:
$ cp id_rsa.pub jupiter.pub
7. Copy the public key file <hostname>.pub to the target user .ssh directory on the target machine:
$ scp <hostname>.pub <targetuser>@<targetmachine>:~/.ssh/<hostname>.pub
For example, if the hostname is jupiter, targetuser is admin, and targetmachine is nmhost, then enter the
following:

$ scp jupiter.pub admin@nmhost:~/.ssh/jupiter.pub
8. Login to the target user account on target machine using SSH:
$ ssh <targetuser>@<targetmachine>
For example, if targetuser is admin and targetmachine is nmhost, then enter the following:
$ ssh admin@nmhost
9. Change the directory to target user .ssh directory:
$ cd .ssh
10. Append the contents of host user public key file to file authorized_keys:
$ cat <hostname>.pub >> authorized_keys
For example, if the hostname is jupiter, then enter the following:
$ cat jupiter.pub >> authorized_keys
11. Change the permission of the file authorized_keys:
$ chmod 644 authorized_keys
12. Exit the target machine and login to target machine again from host machine:
$ ssh <targetuser>@<targetmachine>
For example, if targetuser is admin and targetmachine is nmhost, then enter the following:
$ ssh admin@nmhost

Licenses for Enabling Insight API, Insight CLI, SMS API, SGX API, Lawful Intercept
Provisioning API, and Traffic Manager
Access to the following modules of Insight EMS require the purchase of separate software licenses. Consult your
Sonus sales representative for additional information.
For more details about License Management, refer the page 'Managing Licenses'.
The modules are:
Insight CLI
Insight API
Insight SMS API
Insight SGX API
Lawful Intercept Provisioning API
Insight Traffic Manager
Once you purchase the product, you will be provided a license file with instructions for enabling the
product/functionality along with all applicable documentation. See the Insight EMS User Guide for a list of the
individual licenses that are available and a description of the functionality each enables, and instructions for
installing licenses.
If you install the Insight API, Insight SMS API, Lawful Intercept Provisioning API, and Insight SGX API on a system
other than the Insight server, see Enabling API Licenses on IAS, you must purchase a license for each instance of
an API module you want to use. You cannot share a license between an API module on the Insight server and an
API module on a remote system.
Enabling Mailx
Perform the following procedure to enable mailx:
1. As a user with root privileges, modify the /etc/hosts file.
# vi /etc/hosts
In the hosts file, modify the following:

Append Hostname with domain name to the entry with Hostname and IP
Add Mail server IP, Mail server name, Mail server name with domain name, mailhost

#
# Internet host table
#
:: 1 localhost
127.0.0.1 localhost
10.54.159.29 parus <hostname>.<domain-name>
<mail server ip> <mail server name> <mail server name>.
<domain-name> mailhost
# cd /etc/mail/
Edit the sendmail.cf file with the following configuration changes:
# vi sendmail.cf
a. Append the mail server name to DS.
# "Smart" relay host (may be null)

DS<mail server name>
b. While modifying the sendmail.cf file, replace the PrivacyOptions=authwarnings with

PrivacyOptions=goaway as displayed in the following example:
O PrivacyOptions=goaway
Save and close the sendmail.cf file.

3. Enter the following command to restart mailx:
# service sendmail restart
4. Verify that mailx has been started:
# service sendmail status

sendmail (pid 41594) is running...
sm-client (pid 41605) is running...
User Account Lock Settings
If incorrect password is entered for more than the configured limit (default: 5), user account gets locked for the
configured time (default: 10 minutes). During this period, user cannot login even with the correct password.
You can configure the User Account Lock Settings by following the below procedure:
1. To change the settings of lock time and failed attempts, perform the following:
Edit /etc/pam.d/password-auth file and search for the following line:
auth required pam_tally2.so deny=5 onerr=fail unlock_time=600
Edit the unlock_time value to the required value in seconds.

Edit the deny value to the required value, to modify the number of attempts.
Synchronizing with the NTP Server
Your Unix/Linux Administrator must synchronize the Insight server and all network elements in the deployed network
to the same NTP server. Synchronizing ensures that the timestamps in the Insight logs are consistent with the
timestamps on the other network elements. Failure to do so could also introduce error into certain statistics, most
notably the Trunk Group performance statistics.
If you elect to synchronize with more than one NTP Server, you must ensure that the NTP Servers are also
synchronized. Conflicting time information from multiple NTP Servers may cause Insight system errors.
Procedure
Perform the following procedure to configure NTP server in Linux. All nodes must be set in NTP server.By default,
GSX has NTP server set.

2. Enter the following command to stop the NTP service:
# service ntpd stop
3. Using the vi editor, edit /etc/ntp.conf file and replace the IP in the entry shown below with the NTP
server IP.
For example:
# server 127.127.1.0
4. Enter the following command to synchronize with the NTP server:

4.
# ntpdate <ntp server IP>
5. Start the NTP server:
# service ntpd start
Online Library Installation
The Online Library is available on the Sonus Salesforce Customer Portal. Perform the following procedure to
download and install the Online Library.
1. Download the Online Library from Sonus Salesforce Customer Portal.

2. Copy the SONSdoc<version>_RHEL.tar.Z file to any directory.
3. Decompress the file and then untar it using the following command:
# zcat <filename> | tar xvf -
4. Install the SONSdoc package by executing the following command:
# ./docsInstall.sh
The script installs the new online documentation files. You can access the Online Library through Insight GUI
, Network Mgmnt roll-up, Online Library icon.
Enabling Users to Create Cron Jobs
To enable users to create cron jobs, perform the following steps:
1. Ensure that the user does not exist in the /etc/cron.deny file.
2. Add the user to the /etc/cron.allow file.
Enabling Users to Create at Jobs
To enable users to create at jobs, perform the following steps:
1. Ensure that the user does not exist in the /etc/at.deny file.
2. Add the user to the /etc/at.allow file.
Clearing the Core Files
The core dump files are written to the /home/core directory. The core files must be cleaned up periodically.
Limiting Maximum Login Sessions

For each user the maximum login sessions in a system is currently limited by default to 10. The maximum limit can
be reconfigured for all users except a root user.
Perform the following procedure to limit the maximum login sessions for each user:
Login as root user and enter the following command:
# cat /etc/security/limits.conf
System displays the following:
# <domain> <type> <item> <value>

* hard maxlogins 10
Where, #<domain> <type> <item> <value> is used for informational purpose and will
not appear in the actual output.
You can modify the login limit for a particular user or group. See the following:
Modifying the login limit for a user
If a particular user has specific login limits, the following entry can be used where the <username> must be
replaced with actual user name and value can be modified as per requirement:

<username> hard maxlogins 5
Modifying the login limit for a group
If a particular group has specific login limits, then the following entry can be used where <groupname> must be
replaced with actual group name and value can be modified as per requirement:

@<groupname> hard maxlogins 4
Unlocking the Locked User Account
You can unlock an account if it is locked due the following reasons:
Failed Login Attempts
Performing the following procedure to unlock an account due to failed login attempts:

# pam_tally2 -u <username> --reset
Example output of the above comment for username ‘user01’:
Login Failures Latest failure

user01 0
Inactive Account
Perform the following procedure if the account is locked due to user inactivity:
# passwd -u <username>
For example, system displays the following if the user is user01:
# passwd -u user01
Modifying user session time-out interval
Perform the following procedure to modify the user session time-out interval.
1. Login as root user and modify ClientAliveInterval property:
# vi /etc/ssh/sshd_config
The ClientAliveInterval is calculated in seconds. By default, the user session time-out interval is 750 seconds.
For example, if session time-out interval is one hour, then enter 3600 seconds.
ClientAliveInterval 3600
2. Restart sshd server using "service sshd restart":

Password
You can change the password, modify its aging, and perform several other tasks. See the following topics for
information:
Modifying Password Aging
Perform the following procedure to modify the password aging:
Login as root user and modify maximum password aging days field:
# chage -M <MAX_PASS_DAYS> <username>
By default, the password expires in 90 days.

For example: If the username is user01 and maximum password aging days is 90, then enter the following:
# chage -M 90 user01
Restricting the User to Change Password on First Login
Perform the following procedure to create first password and force the user to change password on first login:
1. Login as root user and after creating the user, assign a default password:
# passwd <username>
For example, if the username is user01, then enter the following:
# passwd user01
2. Compel the user to change the password during first time login:
# chage -d 0 <username>
# chage -d 0 user01

Change Password
Perform the following procedure if root user needs to change the other user password:
1. To change the other user password as a root user, enter the following command:
# passwd <username>
# passwd user01
2. To change your own password, enter the following command:
# passwd
Setting Permissions
Perform the following procedure to set permissions for a normal user to execute privilege commands:
1. To add permission on a particular command, enter the following command:
# chmod +s <absolute_path_to_command_binary_file>
For example, to add the setuid permission on passwd command, enter the following
# chmod +s /usr/bin/passwd
2. To remove permission on a particular command, enter the following command as:
# chmod -s <absolute_path_to_command_binary_file>
For example, to remove the setuid permission on passwd command, enter the following command:
# chmod -s /usr/bin/passwd
Changing the GRUB Password
Grub password protects the boot loader. By default, the grub password for the boot loader is sonus.

Perform the following procedure to change the grub password:
1. Login as root user and execute the following command to generate the encrypted password:
# grub-crypt --md5
2. When the system prompts, re-enter the password two times.

An encrypted password appears.
3. Copy the password and replace the password in the file locations /etc/grub.conf and
/boot/grub/menu.lst.
Following is an example to replace password in any one of the file locations:
hiddenmenu
password --encrypted $1$1TGeX0$9TpQF8P1GDxPhTqFGR7Mg1
title Red Hat Enterprise Linux Server (2.6.32-220.7.1.el6.x86_64)
Deploying LNP Adaptor
The Local Number Portability (LNP) Adaptor is not deployed by default on the Insight server.
To deploy LNP Adaptor, execute the following script as root user.
/opt/sonus/ems/conf/deployLNPApplication.sh
1. Login as insight user and enter the following command to stop EMS:
$ /opt/sonus/ems/sonusEms stop
If you are using a EMS HA systems, you can enter the following command to stop EMS.
2. Enter the following command to change the directory:
$ cd /opt/sonus/ems/conf
3. Execute the following command to deploy LNP Application on the EMS server:

3.
$ ./deployLNPApplication.sh
4. Enter the following command to restart EMS:
If you are using a EMS HA systems, you can enter the following command to start EMS.
5. For an HA or DR setup, ensure LNP Adaptor is deployed on all the Insight servers. To deploy LNP Adaptor
on other Insight systems, repeat Steps "1" to "4" on that server.
Changing Timezone and Network Configuration
The existing timezone and network configurations of EMS server can be changed using the Sonus Network
Configuration Tool. Changing the network configuration is optional. Sonus Network Configuration Tool facilitates
changing the Hostname conifguration, IP address and Interface configuration, Time server, and Time Zone
configuration. The Sonus Network Configuration Tool is invoked by executing the script sonus_netconfig
available in the path /sbin/sonus_netconfig.
After changing the timezone and network configuration, you must relogin and then run /opt/sonus/ems/
conf/configureJumpstart.sh.
To change time zone or network configuration execute the following steps:
1. Start the network configuration tool, by executing the following command:
/sbin/sonus_netconfig
2. The following Sonus Network Configuration screen is displayed. It allows you to change the Hostname, IP
address for network interfaces, Time Zone, and Time Server.
Press Space key on the respective configuration, which you want to change. After changing the
configurations, use TAB key to select SAVE AND QUIT and press Space to write the changes to
the files. If you EXIT, all changes are discarded.

Figure 89: Sonus Network Configuration Tool
3. To change the respective network configuration, select it from the menu.

a. To change Hostname, select Hostname and press Space. The following screen is displayed.
The EMS hostname is limited in length to 64 characters. The hostname can only contain
lowercase letters [a-z] and digits [0-9]. The hostname cannot start with a digit. Special
characters including hyphen are not allowed in hostname.
In the Host Configuration Screen, specify the Hostname, Primary DNS and DNS Search Path details.

Specify the IP Address, subnet mask, and gateway IP Address for eth0 network interface. Use the Tab
IP Address details.
c. Use the Arrow keys to select Time Zone and press Space key to configure the Time Zone. The default
Time Zone currently being used by system, is highlighted in Time zone settings. Select the nearest
Time Zone for the system and press Tab key to select OK and press Space to save the Time Zone
settings.

Figure 93: Timezone
d. Use the Arrow keys to select Time Server and press Space key to change the IP address of TIme
server and press Tab key to select OK and press Space to save the Time Server settings.
Figure 94: NTP Time Server
Once the settings are saved, you are redirected to the screen shown in Step - 2. Press Tab key to
select 'Save and Quit' and press Space key to save the changes made and manipulate the respective
files and close the configuration tool.
Standalone Specific Post-Installation or Upgrade Tasks

The standalone specific post-installation or post-upgrade tasks to be performed for Standalone (SA)
mode are:
Enabling or Disabling HTTP access on the EMS Standalone Server

Managing IP Bonding for a non-HA System
Configuring Multiple Network Interfaces
Enabling or Disabling HTTP access on the EMS Standalone Server

In this section:
Enabling HTTP access on the EMS Standalone Server

Disabling HTTP access on the EMS Standalone Server
The Lawful Intercept servers (Verint and Utimaco) do not support https. If http access is disabled on EMS,
the Lawful Intercept servers cannot communicate with EMS.
The following section describes the procedure to enable HTTP access to the EMS standalone server:
1. As user insight, stop Insight using the command:
2. To enable the access to HTTP, enter the following command as root user:
# /opt/sonus/ems/conf/security/enableHTTP.sh

Sonus EMS is not running now. Script can proceed
Executing /opt/sonus/ems/conf/configHttp -
internalProtocol http to change Insight internal
protocol to http
The old Insight internal protocol was https
The old Insight HTTP port was 80
The old Insight HTTPS port was 443
Changing Insight internal protocol to http
Updating httpPort property in SystemConfig to current
HTTP port 80
run sqlplus UPDATE dbimpl.config_properties SET
PROPVALUE='http' where
propname='sonus.system.apiDeployProtocol'
...........................................
............................................
Completed changing protocol to http. Please restart
Sonus Insight.
If you have any IAS registered with the system, then
execute the same procedure on each IAS also by following
the procedures provided in the Insight User Guide.
3. As user insight, start Insight using the command:
Perform the following procedure to disable HTTP access to the EMS Standalone server:
1. As user insight, stop Insight using the command:
2. To disable the access to HTTP, enter the following command as root user:
# /opt/sonus/ems/conf/security/disableHTTP.sh

Executing /opt/sonus/ems/conf/configHttp -
internalProtocol https to change Insight internal
protocol to https
The old Insight internal protocol was http
Changing Insight internal protocol to https
HTTPS port 443
PROPVALUE='https' where
propname='sonus.system.apiDeployProtocol'.....................................................
the Partitioning, OLAP, Data Mining and Real
Application Testing options
Modifying /opt/sonus/jboss/server/insight/deploy/
jbossweb.sar/server.xml
Done
Completed changing protocol to https. Please restart Sonus
Insight.
If you have any IAS registered with the system, then execute
the same procedure on each IAS also by following the
procedures provided in the Insight User Guide
3. As user insight, start Insight using the command:
Managing IP Bonding for a non-HA System
Overview of IP Bonding and the configure NICTeaming Script
Sonus recommends using IP Bonding to provide non-HA systems with uninterrupted access to a network when a
network interface on the system fails or to protect the system from a single-switch failure. This is achieved by
creating a multipath group on the system, which consists of a primary and standby interface (Sonus recommends
that the primary interface and the standby interface be on different cards if possible). If a failure occurs in the
primary interface or its network adapter, the system automatically switches all the network access from the failed
interface and/or adapter to the standby interface.
The configureNicTeam script will create, revert, or delete IP bonding group, based on the
values specified while running the script.
Values You Provide
The configureNicTeam script will prompt you for the following values. You can use Table to record the values that
you will enter when you run the script.
All of the IP addresses you provide must be in the same subnet.

Primary interface: The physical interface that will handle the network access for the multipath group if the
interface is working.
Secondary interface: The physical interface that will handle the network access for the multipath group if the

primary interface fails. Sonus recommends that the primary interface and the standby interface be on different
cards if possible.
IP Bonding group name: The name of the NicTeam multipath group.
Data IP Addresses: The data IP addresses that will be supported by the multipath group. The data
addresses, test addresses, and target addresses must all be in the same subnet.
Netmask: The netmask for the IP addresses.
Gateway: The Gateway IP address.
Table 27: Information needed to create IP Bonding using configureNICTeam create script
Item Value (fill in)
Primary interface for multipath group
Secondary interface for multipath group
IP Bonding group name
Data IP addresses
Netmask
Gateway
Exiting the Script
To exit the script at any time, press Ctrl-C.
Creating an IP Bonding Group
Use the following procedure to create an IP Bonding group. See Values You Provide for a description of the values
you will be entering.
1. On the Insight server, begin the NiCTeam script:
# cd /opt/sonus/ems/conf/
# ./configureNicTeam create
If the Insight server is part of an HA system, the script exits.

2. Messages appear that give an overview of the script. When prompted, press ENTER to continue.
3. Messages appear that explain the conventions used in the script. When prompted, press ENTER to continue.
4. The prompt Primary interface appears, followed by a list of interfaces.
Enter the name of the primary interface, and press ENTER.
5. The prompt Secondary interface appears, followed by a list of interfaces.
Enter the name of the secondary interface, and press ENTER.
6. The following prompt appears.
bonding group name: (Sonus-Mgmt)
Either accept the default value for the multipath group name by pressing ENTER, or type a name and press

ENTER.
At this point you will enter the IP data address that you wish to be used by
the NIC Teaming Group.
Press enter to continue
Press ENTER to continue.

8. The following prompt appears to enter Data IP address, Gateway IP address and netmask.
Data IP address for Teamed interface: (10.54.159.28)

Please provide the Gateway IP Address: (10.54.159.1)
Please provide a netmask that applies to the addresse you have provided:
(255.255.255.0)
Enter the details.

9. The prompt confirms the entries.
You entered the following:

Bonding Group Name: Sonus-Mgmt
Primary interface: eth0
Secondary interface: eth1
Data IP Address: 10.54.159.28
Gateway IP Adress: 10.54.159.1
Netmask: 255.255.255.0
Are these values correct? [y,n]
Type y and press ENTER to continue.
The program will now show you the exact changes that will be made. Press enter
once you understand the changes that will be made. After you have reviewed all
of the changes, you will be asked if those changes should be written to the
associated files. You must either accept all changes or none at all. You may
edit the changes in the various files as needed after the program completes.
Press enter to continue
Press ENTER to continue.

11. This is followed by the prompt:
Are you ready to commit these changes? [y,n]
Type y and press ENTER to continue.
12. Messages appear listing the files that are being created and stating that the changes are complete.
13.

13. The Bonding configuration can be viewed using ifconfig.
Reverting IP Bonding
After creating an IP Bonding, you can also revert back the IP Bonding to its original state. Reverting the IP Bonding
removes the customized IP Bonding and restores the bonded interface configuration from the backup file.
To revert the IP Bonding that was created to its original state, execute the following steps:
1. On the Insight server, begin the NiCTeam script configureNicTeam with revert parameter:
# ./configureNicTeam revert
This script will delete all the bonds having backup
2. Messages appears if you are ready to commit the changes. When prompted, press y to revert back to the
original IP Bonding.
3. The script removes the customized bonding and reverts back to the original state. After removing the
customized bonding, restarts the network services.
Found Backup for Bond Sonus-Mgmt

Reverting the Bond Sonus-Mgmt
Reverting orignal interface settings... [ OK ]
Removing the interfaces from the bond... [ OK ]
Bringing down the bond... [ OK ]
Removing the bond... [ OK ]
Modifying the bonding.conf [ OK ]
Removing the bonding files [ OK ]
Restarting network services...
Shutting down interface eth0: [ OK ]
Shutting down loopback interface: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface eth0: [ OK ]
The specified Network Bond is reverted and network services are restarted along with bringing up the NIC
interfaces involved in Network bonding.
Removing IP Bonding
This procedure is used to remove the IP Bonding. It asks for new values for network interfaces that were earlier part
of the IP Bonding.
To remove the IP Bonding, execute the following steps:
1. On the Insight server, begin the NiCTeam script configureNicTeam with remove parameter:

1.
# ./configureNicTeam remove
2. Messages appears with Network Bond Names along with interface names which are part of the repsective
Network Bond.
Bonds available on this machine :

Bond : Sonus-Mgmt
Interfaces in this bond Interface : "eth6" Interface :

"eth7"
Bond : bond0
Interfaces in this bond
3. Specify the Network bond name, which needs to be removed. Additionally, you also need to specify the new
IP address to be assigned to NIC interfaces that were part of the IP Bonding that is being removed.
Please select the bond name to be removed : [Sonus-Mgmt bond0]: Sonus-Mgmt

Enter the ip Address of the eth6 interface :
Enter the ip Address of the eth7 interface :
Enter the gateway of the eth6 interface :
Enter the gateway of the eth7 interface
4. A confirmation message, with Network Bonding which you want to remove and specified IP addresses for
Network interfaces is displayed.
Please confirm your entries. No changes will be made at this point.

Bonding Group Name: Sonus-Mgmt
First Interface: eth6
First Interface IP:
First Interface Gateway:
Second interface: eth7
Second Interface IP:
Second Interface Gateway:
5. Ensure and verify the Network Bonding you want to remove. Press y to continue and remove the specified
Network Bonding and configure the new IP address values for NIC interfaces.

Are these values correct? [y,n] y
Updating interface with properties...
Removing Bonding of Sonus-Mgmt ...
Removing interface eth6 from the Bond...
Removing interface eth7 from the Bond...
Bringing down the bond Sonus-Mgmt...
Bringing up first interface eth6...
Bringing up second interface eth7...
Removing the bonding files...
Unbonding completed successfully!!
Restarting network services...
Shutting down loopback interface: [ OK ]
Bringing up loopback interface: [ OK ]
The specified Network Bond is removed and network services are restarted along with bringing up the NIC
interfaces involved in Network bonding.
Configuring Multiple Network Interfaces
When a server has multiple network interfaces, Sonus Insight requires the proper configuration of the /etc/hosts file.
The configuration information in this file allows the user to select the network interface to which a node connects.
During the Node Registration process, the user can select the desired IP Address from the Mgmt Client IP Address
list on the Node Registration screen.
Example of an Entry in /etc/hosts File
The following is an example of an entry in a /etc/hosts file illustrates a server, samplehost, having two network
interfaces with IP Addresses of 38.45.67.123 and 38.33.54.26.
#
#
127.0.0.1 localhost
38.45.67.123 samplehost samplehost.yourcom.com
38.33.54.26 samplehost
38.45.68.03 otherhost
HA Specific Post-Installation or Upgrade Tasks

The HA specific post-installation or post-upgrade tasks to be performed for High-Availability (HA) mode
is:
Enabling or Disabling HTTP access on the HA Linux
Enabling or Disabling HTTP access on the HA Linux

This section describes how to enable or disable HTTP access on the HA Linux.
High-level steps
The high-level steps for enabling or disabling HTTP access are:
Step number Action
1 Stop EMS on the HA server.
2 Delete resources on the HA server.
3 To enable HTTP access perform the following steps:
1. Execute the script enableHTTP.sh on the primary server first.

2. Execute the script enableHTTP.sh on the non-primary server.
or
To disable HTTP access perform the following steps:
1. Execute the script disableHTTP.sh on the primary server first.

2. Execute the script disableHTTP.sh on the non-primary server.
4 Register resources on the HA server.
5 Start EMS on the HA server.
Enabling HTTP access on the HA Linux
To enable the HTTP access for HA Linux server, perform the following steps:
1. Log on as root user to the primary server.

2. Change the directory to /opt/sonus/ems/conf/HA/RAC:
3. Stop EMS on the HA server, by executing the command sonusEMS stopAll
# ./sonusEMS stopAll
4. Delete resources on the HA server, by executing the command hamgmt deleteAll
# ./hamgmt deleteAll
5. To enable HTTP access, change the directory to /opt/sonus/ems/conf/security on the primary server
by executing the following command:

5.
# cd /opt/sonus/ems/conf/security
6. Enable HTTP access on primary server, by executing following command:
# ./enableHTTP.sh
7. Login as root user to non-primary server and change the directory to

/opt/sonus/ems/conf/security/
8. Enable HTTP access on non-primary server, by executing following command:
# ./enableHTTP.sh
9. On the primary server, change the directory path to /opt/sonus/ems/conf/HA/RAC/
10. Register the resources using the command hamgmt createAll on the primary server.
# ./hamgmt createAll
11. Start EMS on the HA server, by executing the command sonusEMS startAll on the primary server.
# ./sonusEMS startAll
Disabling HTTP access on the HA Linux
To disable the HTTP access for HA Linux server, perform the following steps:
1. Log on as root user to the primary server.

2. Change the directory to /opt/sonus/ems/conf/HA/RAC:

5. To disable HTTP access, first change the directory to /opt/sonus/ems/conf/security on the primary
server by executing the following command:
6. Disable HTTP access on primary server, by executing following command:
# ./disableHTTP.sh
7. Login as root user to non-primary server and change the directory to

/opt/sonus/ems/conf/security/
8. Disable HTTP access on non-primary server, by executing following command:
# ./disableHTTP.sh
9. On the primary server, change the directory path to /opt/sonus/ems/conf/HA/RAC/

11.
This page provides links for managing account name and password information associated with the Insight.

Insight default accounts include those associated with Linux and those associated with the underlying Insight
database. The Linux accounts include both those that are common to all Sonus Linux platforms and those that are
specific to Insight. These default accounts and their associated default passwords are listed in this section:
Strong and Weak Passwords
The choice between strong or weak passwords will be given during installations.
The strong passwords have more restrictions and require that a new password be entered during the installation.
The strong passwords do not have a default value, while the weak passwords do have a default value.
Common Sonus Linux Accounts
Account Name Default Password
admin admin
root sonus
Insight-Specific Linux Accounts
insight insight
oracle oracle
Insight Database Accounts
Account Name Default Password (weak passwords only)
dbimpl dbimpl
sys change_on_install
system manager

Insight Agent Connection Account
admin admin
Netcool Database Account
Insight_Admin_User sonus
root sonusfm
EMS Keystroke Password
The default EMS Keystore password (weak passwords only) is sonusems.
For complete Sonus products account and password details, refer to Sonus Products Password and Security
Management Reference.

The following section describes the procedure for changing the password.
Changing the Insight User Password and Password Expiration Behavior
Changing the Insight Agent Connection Account Password
Changing the Insight Database Password for the IAS from the Insight System
Changing the System Database User Password
Changing the Netcool Database User Password for the Insight_Admin_User
Changing the Netcool Database User Password for the Root User
Changing the EMS Keystore Password
Changing the Password or Password Behavior of the insight User for the IAS System
Changing the Database Password for EMS Standalone System
Changing the Database Password for EMS HA System
All Linux Accounts Except for User insight
For all Linux accounts other than insight, change the password using the Unix/Linux “ passwd” command.
The following user password restrictions exist by default. Sonus recommends that you do not change these
restrictions.
The minimum number of characters in the password is 10.

The minimum number of alphabetic characters in the password is 4.
The minimum number of special characters in the password is 2.
The maximum number of repeated characters in the password is 2.
The four most recent passwords value may not be used.
Changing the Insight User Password and Password Expiration Behavior
This section describes how to change the insight user password with the changeInsightPassword.sh script.

This section includes the following:
Overview
Change the insight user password after a Kickstart if you did not use the strong password option when running the
configureJumpstart.sh or emsMigrate.sh script. This changes the insight user password from the previous value.
Sonus recommends that you also periodically change the insight user password.
This procedure uses a script to change the password and to make the corresponding changes to the Netcool
Process control user. You do not need to re-perform Netcool configuration.
This procedure also allows you to set the password expiration behavior to non-expiring or to expiring, and to set the
expiration values.
CAUTION
You must use the following procedure to change the password for the insight user. Do not use the passwd
command, which would result in a misconfiguration of Netcool.
Password Restrictions
The insight user password has the following restrictions (unless you use the -v option described in the procedure):
The password must be at least 8 characters long.

The password must contain characters from at least two of the following categories:
– lowercase letters
– uppercase letters
– numbers
– special characters
Procedure
To change the password and/or the password expiration behavior for the insight user, perform the following
procedure.
1. Log in as root.
2. Run the setup script to configure the insight user password/password expiration as follows:
# ./changeInsightPassword.sh -a "-n <min_days> -w <warn_days> -x <max_days>"
Where:
<min_days> represents the minimum number of days that must pass before the user can change the
password.
<warn_days> represents the number of days before the password expiration when the user is warned.
<max_days> represents the maximum number of days that a password is valid. If you enter -1, password
expiration is turned off, and you do not need to enter the -n or -w arguments.
The -a and the quotation marks are needed if you are entering the -n, -w, or -x arguments.
You can change the password behavior to non-expiring by entering ./changeInsightPassword.sh

without any arguments. The following options may also be used when entering the
./changeInsightPassword.sh command:

-c: The new password will be requested once, and you will not be prompted to re-enter it.
-v: The password will not be checked to see if it meets the password restrictions.
3. If Insight is up and running, the following prompt appears:
Insight is currently running. You must shut down Insight (including all of the
FM processes) before running this script. Do you want to continue [y|Y,n|N]?
(Default:Y)
Enter Y.
Please enter new password:
Enter the new password if you are changing it, or enter the old password if you are only changing the
expiration behavior. Unless you used the -v option in Step "1", the password must meet the restrictions listed
in "Password Restrictions".
If you used the -c option in Step "1", continue to Step "6".
5. When prompted, re-enter the password you entered in Step "4".
If the server is not part of a DR or HA system, continue to Step "9".
6. If the system is part of a DR or HA system, a prompt appears that asks if you want to change the insight user
password on the other systems.
Enter Y.
7. When prompted, enter and re-enter the root password for each of the other Insight servers.
If you have entered a wrong password, for the remote servers, the following message appears:
Connecting to HA standby system failed. Do you want to retry [y|Y|n|N]?

(Default:Y)
(or)
Connecting to DR target system failed. Do you want to retry [y|Y|n|N]?
(Default:Y)
(or)
Connecting to DR target standby system failed. Do you want to retry [y|Y|n|N]?
(Default:Y)
8. Enter N and then give the right password.

9. The script runs to completion.
The default Agent connection account/password combination is admin/admin. To change the password, perform

the following procedure, which uses the jash shell utility:
1. As root, enter the following:
# /opt/sonus/sonusComm/bin/jash
2. At the % prompt, enter the following (this assumes the current password is admin):
% logon admin admin
success
% admin changePassword admin <existing password> <new password>
where
admin is the account name
<existing password> is the current password, such as admin
<new password> is the new password
4. To exit the jash shell, enter the following:
% exit
5. Change the Agent Password field in the Register Insight Node screen. See the “Insight Administration”
chapter of the Insight EMS User Guide.
Overview
This section describes how to set the Insight database password for an IAS by running a script from the Insight
server. This procedure is only required if the password on the IAS was not changed when performing Changing the
Database Password for EMS Standalone System.
Procedure
To change the Insight database password for an IAS system by running a script on the Insight server, perform the
following:
1. As root on the Insight server, enter the following commands:

1.
# ./remoteIasMgmt.sh resetDbPassword <client_ip_address>
where <client_ip_address> is the IP address of the IAS on which you want to update the Insight
database password.
What is the password of the root user on the other system?
Enter the password of the root user on the IAS.

The Insight database password is changed on the IAS.
The script runs to completion.
This section describes how to change the system database user password with the
changeSystemDbPassword.sh script. This section includes the following:
The system database user password has the following restrictions (unless you use the -v option described in the
procedure):

– numbers
– special characters (the only special characters allowed are _ and #)
Procedure
To change the system database user password, perform the following:
# ./changeSystemDbPassword.sh
The following options may be used when entering the ./changeSystemDbPassword.shcommand:


2.
Enter the password. Unless you used the -v option in Step "1", the password must meet the restrictions listed
in Password Restrictions.
3. When prompted, re-enter the system database user password.
This section describes how to change the Netcool database user password for the Insight_Admin_User with the
changeNetcoolDbInsightPassword.sh script.
The user password has the following restrictions (unless you use the -v option described in the procedure):

– numbers
– special characters (the only special characters allowed are _, $, and #)
Procedure
To change the Netcool Database User Password for the Insight_Admin_User user, perform the following steps:
# ./changeNetcoolDbInsightPassword.sh
The following options may be used when entering the ./changeNetcoolDbInsightPassword.sh

command:
2. If Insight is not running, the following prompt appears:
FM is not running. About to start FM now. Do you want to continue [y|Y,n|N]?

(Default:Y)
Enter Y.

Enter the password. Unless, you used the -v option in Step 1. The password must meet the restrictions listed
4. When prompted, re-enter the password.
This section describes how to change the Netcool database user password for the root user with the
changeNetcoolDbRootPassword.sh script. This section includes the following:
The password has the following restrictions:

– numbers
Procedure
To change the Netcool Database User Password for the root user, perform the following steps:
# ./changeNetcoolDbRootPassword.sh

(Default:Y)
Enter Y.

3.
Enter the password. The password must meet the restrictions listed in Password Restrictions.
This section describes how to change the EMS keystore password with the changeKeystorePassword.sh script.
This procedure can be used after you obtain your own SSL certificate and import it, see SSL Certificate Installation
Procedures. This procedure cannot be used with the demo site certificate that comes with Insight.
Procedure

– numbers
Procedure
To change the EMS keystore password, perform the following:
1. As root user, enter the following:
# ./changeKeystorePassword.sh
Please enter the current EMS keystore password:
Enter the password.

3.
Please enter the private key alias:
Enter the private key alias.
If genCertRequest script is used to generate the private key, then the private key alias is insight.
For more information, see SSL Certificate Installation Procedures.
Please enter the private key password:
Enter the private key password.
Enter the new EMS keystore password. The password must meet the restrictions listed in Password
Restrictions.

Changing the Password or Password Behavior of the insight User for the IAS System
To change the insight user password of the IAS system or to change the password expiration behavior (the IAS has
an expiring insight user password by default), use the passwd command.
Changing the Insight Agent Connection Account Password for the IAS System
# /opt/sonus/sonusComm/bin/jash
% logon admin admin

success
where
% exit
5. Change the Agent Password field in the Register Insight Node screen. See the “Insight Administration” of the
Insight EMS User Guide.
Changing the Database Password for EMS Standalone System
This section describes how to change the Insight database user password with the changeDbPassword.sh script.
The Insight database password has the following restrictions (unless you use the -v option described in the
procedure):

– numbers
Insight Database Password on IAS Systems
When using the changeDbPassword.sh script to change the Insight database password on the Insight system, the
script will also change the database password on any IASs that are registered to the Insight system and that are
currently up. You will be prompted for the password of the root user on each IAS.

CAUTION
If an IAS is not up when you run the changeDbPassword.sh script, you will need to change the password
when the IAS is up by performing Changing the Insight Database Password for the IAS from the Insight
System. If the Insight database password on the IAS does not match the Insight database password on the
Insight server to which it is registered, the database user (dbimpl) will be locked out of the database, and
Insight will not function correctly. To unlock the database, run the following script: /opt/sonus/ems/conf
/unlockDbimplUser.sh
Procedure
To change the Insight database password, perform the following steps:
# ./changeDbPassword.sh
The following options may be used when entering the ./changeDbPassword.sh command:
Insight is currently running.You must shut down Insight (including all of the
(Default:Y)
Enter Y.
4. When prompted, re-enter the Insight database password.

5. The script searches for any IASs that are registered to this Insight system and that are up. For each IAS it
finds, the following prompt appears:


6. If an IAS was not found when you changed the Insight database password, you will need to change the
password when the IAS is up. See Changing the Insight Database Password for the IAS from the Insight
Insight will not function correctly. To unlock the database, run the script
/opt/sonus/ems/conf/unlockDbimplUser.sh.
Changing the Database Password for EMS HA System
This section describes how to change the EMS database user password with the changeDbPassword.sh script.
procedure):

The password must contain characters from at least two of the following categories: – lowercase letters –
uppercase letters – numbers – special characters (the only special characters allowed are _ and #)
CAUTION
when the IAS is up by performing Changing the Insight Database Password for the IAS from the Insight
Insight will not function correctly. To unlock the database, run the following script: /opt/sonus/ems/conf
/unlockDbimplUser.sh
High-level steps
The high-level steps for changing the Database password are:
Step number Action
1 Stop EMS on the HA server.
2 Delete resources on the HA server.
3 Change the EMS Database Password by executing the script changeDbPassword.sh

4 Register resources on the HA server.
5 Start EMS on the HA server.
Changing the EMS Database Password

2. Change the directory to /opt/sonus/ems/conf/HA/RAC by executing the following command:
5. Change the EMS Database Password by executing the following command as root user.
a. Change the directory to /opt/sonus/ems/conf, by executing the following command:
b. Execute the script changeDbPassword.sh to change the EMS Database Password with desired
options (-c or -v):
The following options may be used when entering the changeDbPassword.sh command:
c. If Insight is up and running, the following prompt appears:
Insight is currently running.You must shut down Insight (including all of

the FM processes) before running this script. Do you want to continue
[y|Y,n|N]? (Default:Y)
Enter Y.
d. The following prompt appears:

d.
Enter the password. Unless you used the -v option in Step "5a", the password must meet the
restrictions listed in Password Restrictions.
If you used the -c option in Step "5a", continue to Step "5f".
e. When prompted, re-enter the Insight database password.

f. The script searches for any IASs that are registered to this Insight system and that are up. For each
IAS it finds, the following prompt appears:

g. If an IAS was not found when you changed the Insight database password, you will need to change
the password when the IAS is up. See Changing the Insight Database Password for the IAS from the
Insight System. If the Insight database password on the IAS does not match the Insight database
password on the Insight server to which it is registered, the database user (dbimpl) will be locked out
of the database, and Insight will not function correctly. To unlock the database, run the script
/opt/sonus/ems/conf/unlockDbimplUser.sh.
6. Change the directory to /opt/sonus/ems/conf/HA/RAC by executing the following command:
This completes changing the EMS Database (DB) password.
Configuring IPv6

This section contains the procedure to migrate the EMS in the network from IPv4 to IPv6 addresses.
Update the Device with the IPv6 Management Address from the EMS Node Registration Window
Prerequisites
Before migrating Sonus network elements from IPv4 to IPv6, see the Sonus Network Solution IPv4 to IPv6 Migration
Guide to understand the implementation of complete network migration of multiple Sonus products.

You can move any of the managed IP interfaces in EMS to IPv6 when the configured Sonus devices are migrated to
IPv6. Until the configured Sonus devices are migrated to IPv6, EMS can continue to manage all the configured
devices over the existing IPv4 addresses.
Perform the following procedure to enable IPv6 on the EMS standalone server.
1. Log in as root.
2. Append "NETWORKING_IPV6=yes" in /etc/sysconfig/network file.
3. Edit the following file:
# /etc/sysconfig/network-scripts/ifcfg-<interface name>
where the <interface name> is the name of the interface on which the IPv6 needs to be enabled.
You can obtain the interface name by executing the following command:
# ifconfig
For example, you can execute the command as follows:
# ifconfig
eth0 Link encap:Ethernet HWaddr 2C:76:8A:50:00:E0
inet addr:10.54.159.28 Bcast:10.54.159.255 Mask:255.255.255.0
inet6 addr: fe80::2e76:8aff:fe50:e0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:26616624 errors:0 dropped:0 overruns:0 frame:0
TX packets:15355760 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:32241613772 (30.0 GiB) TX bytes:9634299086 (8.9 GiB)
Interrupt:32
In this example, eth0 is the name of the interface on which IPv6 needs to be enabled.
Edit the following file:

/etc/sysconfig/network-scripts/ifcfg-eth0
4. Add the following entry to the /etc/sysconfig/network-scripts/ifcfg-eth0 file, save, and exit:
IPV6ADDR=<ipv6address>/<prefix>
IPV6_DEFAULTGW=<ipv6gatewayip>
For example,
IPV6ADDR=fd00:10:6b50:4020::56/60
IPV6_DEFAULTGW=fd00:10:6b50:4020::1
where fd00:10:6b50:4020::56 is the IPv6 address of the server.
5. Open the /etc/hosts file.

Where ::1 localhost is added as the first line.
6. Move ::1 localhost to a place after 127.0.0.1 localhost.
7. Add an entry for IPv6 towards the end.

<ipv6 address> <hostname>
For example, FD00:10:6B50:4160::33 sonusems
where FD00:10:6B50:4160::33 is the IPv6 address of the server
where sonusems is the hostname of the server
8. Enter the following command to restart physical service:
# service network restart
9. Verify IPv6 address by executing the following command:
# ifconfig
This command should list both IPv4 and IPv6 addresses.
10. Login as user insight and restart the EMS services using the following commands:

After enabling IPv6 on the EMS server, you need to upgrade the target devices to IPv6 and enable IPv6
management IPv6 address on the device. For more information, refer to the respective device’s Installation
Guide.

You can move any of the managed IP interfaces in EMS to IPv6 when the configured Sonus devices are migrated to
IPv6. Until the configured Sonus devices are migrated to IPv6, EMS can continue to manage all the configured
Perform the following procedure to enable IPv6 on the EMS standalone server.
1. Log in as root.
2. Append "NETWORKING_IPV6=yes" in /etc/sysconfig/network file.
3. Edit the following file:
# /etc/sysconfig/network-scripts/ifcfg-<interface name>
# ifconfig
# ifconfig
eth0 Link encap:Ethernet HWaddr 2C:76:8A:50:00:E0
inet addr:10.54.159.28 Bcast:10.54.159.255 Mask:255.255.255.0
inet6 addr: fe80::2e76:8aff:fe50:e0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:26616624 errors:0 dropped:0 overruns:0 frame:0
TX packets:15355760 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:32241613772 (30.0 GiB) TX bytes:9634299086 (8.9 GiB)
Interrupt:32
In this example, eth0 is the name of the interface on which IPv6 needs to be enabled.
/etc/sysconfig/network-scripts/ifcfg-eth0
4. Add the following entry to the /etc/sysconfig/network-scripts/ifcfg-eth0 file, save, and exit:

4.
IPV6ADDR=<ipv6address>/<prefix>
IPV6_DEFAULTGW=<ipv6gatewayip>
For example,
IPV6ADDR=fd00:10:6b50:4020::56/60
IPV6_DEFAULTGW=fd00:10:6b50:4020::1
where fd00:10:6b50:4020::56 is the IPv6 address of the server.

Where ::1 localhost is added as the first line.

# service network restart
# ifconfig
10. Login as user insight and restart the EMS services using the following commands:
Guide.
Update the Device with the IPv6 Management Address from the EMS Node

Registration Window
After enabling IPv6, you need to update (which includes un-registration of IPv4 device, then register device with
IPv6 address where mgmt client is IPv6) the device with the IPv6 management address from the EMS node
registration window.
The following is the procedure to re-register the device with the IPv6 management address:
1. In the EMS Node Registration window, verify if both IPv4 and IPv6 addresses are displayed in the Mgmt
Client IP Address field.
Figure 95: EMS Node Registration Window
2. Update the management client and device IP with IPv6 address and click the Update button.
3. Click Register.

This page provides the links pertaining to information for installing ISO image based on different Network
Connections.
It contains the following topics:
Local Installation using a Laptop Directly Connected to the Server Through iLO Port
Remote Installation
For detailed information, about installation using a PC or laptop connected on the same network as the iLO, refer the
page: Options for Mounting ISO Image.
Local Installation using a Laptop Directly Connected to the Server Through
iLO Port
For detailed information, about local installation using a laptop directly connected to server through iLO, refer the
page: Options for Mounting ISO Image.
For information, about connecting Windows XP Laptop directly to Server iLO, refer the page: Options for Mounting
ISO Image.
Remote Installation
For information, about performing remote installation from a remote desktop by Sonus Customer support to the PC
or laptop on the same network as the iLO, refer the page: Options for Mounting ISO Image.
Security Settings for HP G8

Security Settings for HP G8

HP G8 iLO Open Ports
Encryption security settings
SSL Certificate Security Settings
IPMI Security
Closing Unused Ports - An Overview
Enabling RPC processes on EMS Standalone server
Disabling the RPC processes on EMS Standalone server
Checking the status of RPC processes on EMS Standalone server
Enabling RPC processes on HA Server
Disabling the RPC processes on EMS HA server
Checking the status of RPC processes on EMS HA server
Enabling RPC processes on IAS Server
Disabling the RPC processes on IAS Server
Checking the status of RPC processes on IAS Server
HP G8 iLO Open Ports
For details, regarding iLO open ports in a HP DL 380p G8 server, refer this page: Security Settings for HP ProLiant
DL380p Gen8 Server.
Encryption security settings
For details, regarding Encryption security settings, refer this page: Security Settings for HP ProLiant DL380p Gen8
Server.
SSL Certificate Security Settings
For SSL Certificate Security Settings information, refer the page: Security Settings for HP ProLiant DL380p Gen8
Server.
IPMI Security
For IPMI Security details, refer the page: Security Settings for HP ProLiant DL380p Gen8 Server.
The Insight EMS has certain ports which are opened publicly. Most of them are RPC related processes, which are
no longer used in remote agent. For security reasons, these ports are closed from Release 9.2 onwards. Using the
configureRPC.sh script you can enable, disable, or see the status of RPC processes. From release 9.2 onwards,
the RPC processes will be disabled in case of fresh installation of EMS and IAS and when EMS is upgraded from a
previous versions to 9.2 or above. However, if you are upgrading from Release 9.2 to a release higher than 9.2 then
the previous state of RPC processes will be retained.
The configureRPC.sh script when run, interacts with the RPCenabled property in SystemConfig.txt file.
Only EMS uses the SystemConfig.txt file. The IAS does not use SystemConfig.txt file.

When you try to stop RPC process, you might get the following error:
Some of the GSX Devices are using local agent functionality. RPC processes
cannot be stopped. If you want to stop RPC processes, enable remote agent for
all the GSX and rerun this script.
This implies that there are one or more GSX’s registered to the EMS which are still using the RPC process
and hence cannot be disabled. In the node registration page ensure “Use Remote Agent” checkbox is
selected for all the GSX. After “Use Remote Agent” field is updated execute the script again.
To enable RPC process on EMS server, execute the following steps:
1. Enable the RPC processes, by executing the following command:
# /opt/sonus/ems/conf/security/configureRPC.sh start
starting the RPC
Starting rpcbind:
To disable RPC process on EMS server, execute the following steps:
1. Disable the RPC processes, by executing the following command:
# /opt/sonus/ems/conf/security/configureRPC.sh stop
Stopping the RPC
Stopping rpcbind:
To check for the status of RPC processes, execute the following steps:
1. Check the status of RPC processes, by executing the following command:
# /opt/sonus/ems/conf/security/configureRPC.sh status
rpcbind (pid 11990) is running...
To enable RPC process on EMS HA server perform the following commands on primary and secondary servers,
execute the following steps:
1. Enable the RPC processes by perform the following steps on active and standby systems
a.

1.
a. Enable RPC process on active system, by executing the following command:
starting the RPC
Starting rpcbind:
b. Enable RPC process on standby system, by executing the following command:
starting the RPC
Starting rpcbind:

a. Disable RPC process on standby system, by executing the following command:
Stopping the RPC
Stopping rpcbind:
b. Disable RPC process on active system, by executing the following command:
Stopping the RPC
Stopping rpcbind:
# /opt/sonus/ems/conf/security/configureRPC.sh status
To enable RPC process on IAS server, execute the following steps:

1.
# /opt/sonus/ias/bin/configureRPC.sh start
starting the RPC
Starting rpcbind:
To disable RPC process on IAS server, execute the following steps:
# /opt/sonus/ias/bin/configureRPC.sh stop
Stopping the RPC
Stopping rpcbind:
# /opt/sonus/ias/bin/configureRPC.sh status

This section contains configuration tasks for EMS. Some of the administrative tasks are common for EMS
Standalone (SA) and High-Availability (HA) modes, while other administrative tasks are performed differently for SA
and HA. Accordingly, tasks have been divided into common tasks and specific tasks for SA and HA.
Table of Contents
EMS DR Operations

The common administrative tasks for SA and HA are:
Disk Mirroring
Disk Mirroring
This page contains procedures for checking and testing disk mirroring on Insight servers.
Checking the Drive Status

Checking the Status of Mirrors
Testing the Disk Mirroring
Perform the following procedure to check the hpacucli or hpssacli packages:
# rpm -qa |grep -i hpacu
If you see the following output, you can use hpacucli for all disk mirroring procedures.
hpacucli-9.40-12.0.x86_64
# rpm -qa |grep -i hpss
If you see the following output, you can use hpssacli for all disk mirroring procedures.
hpssacli-2.0-23.0.x86_64
Checking the Drive Status
Prerequisites
Determine the hpacucli or hpssacli packages. Refer Disk Mirroring. Depending on the result, use the
appropriate command listed in the following procedure.
Procedure
Perform the following procedure to check the RAID configuration and status of the drives:
1. Check the RAID configuration:

1.
hpacucli ctrl slot=0 show config
OR
hpssacli ctrl slot=0 show config
2. Check the status of first mirror:
hpacucli ctrl slot=0 array A show
OR
hpssacli ctrl slot=0 array A show
3. Check the status of second mirror:
hpacucli ctrl slot=0 array B show
OR
hpssacli ctrl slot=0 array B show
4. Check the first logical drive:
hpacucli ctrl slot=0 ld 1 show
OR
hpssacli ctrl slot=0 ld 1 show
5. Check the second logical drive:
hpacucli ctrl slot=0 ld 2 show
OR

hpssacli ctrl slot=0 ld 2 show
Checking the Status of Mirrors
Prerequisites
Hardware RAID must be configured and Red Hat Enterprise Linux 6.4.2 OS must be installed.
Disks must be in sync and status must be ok.
Procedure
Perform the following procedure to check the status:
1. Login as root user and enter the following command:
OR
Smart Array P420i in Slot 0 (Embedded)

Note: Predictive Spare Activation Mode is enabled, physical drives that are in
predictive failure state will not be available for use as data or spare
drives.
(sn: 50014380210BB730)
array A (SAS, Unused Space: 0 MB)
logicaldrive 1 (419.2 GB, RAID 1, OK)
physicaldrive 1I:2:1 (port 1I:box 2:bay 1, SAS, 450 GB, OK)
array B (SAS, Unused Space: 0 MB)
SEP (Vendor ID PMCSIERA, Model SRCv8x6G) 380 (WWID: 50014380210BB73F)
Testing the Disk Mirroring
Prerequisites

Procedure
Perform the following procedure to test the disk mirroring:
1. Remove one of the disk from raid array A. For example, slot 2.:
2. Enter the following command to check the status after the disk is removed from slot 2::
OR

drives.
(sn: 50014380210BB730)
logicaldrive 1 (419.2 GB, RAID 1, Interim Recovery Mode)
physicaldrive 1I:2:2 (port 1I:box 2:bay 2, SAS, 450 GB, Failed)
50014380210BB73F)
3. Reboot the system.

System must come up without any issues.
4. Insert the new disk of the same size in slot 2 and check the status and enter the following command:
OR

drives.
(sn: 50014380210BB730)
logicaldrive 1 (419.2 GB, RAID 1, Recovering, 4% complete)
physicaldrive 1I:2:2 (port 1I:box 2:bay 2, SAS, 450 GB, Rebuilding)
5. Recovery takes time depending on the amount of data on the disk. Enter the following command to continue
to monitor the disk status:
OR

drives.
(sn: 50014380210BB730)
The status of the physical and logical drive must be OK.

6. Repeat steps "1"to "5" for remaining the slots and check.

This section provides information about the standalone specific administrative tasks. It covers the
following topics:

Configuring Netcool

This section contains the following Insight server administrative tasks:
Checking Insight Version

Stopping the Insight Server
Changing the Insight IP Address
Changing the Hostname for Insight without Changing the IP Address
This section provides information for performing administrative tasks specifically done on EMS Standalone (SA)
server.

To verify the version of Insight installed, enter the following command as user root:
# rpm -qa SONSems
Expected output:
SONSems-V09.03.00-R000.x86_64
To verify the status of the Insight server, as user insight type:
$ cd /opt/sonus/ems
$ ./sonusEms status
Occasionally, it may become necessary to start the Insight server. To do so, use the following commands:
Start the Insight server as user insight as follows:

$ cd /opt/sonus/ems
$ ./sonusEms start
# ./sonusEms -help
Occasionally, it may become necessary to stop the Insight server. To do so, use the following commands:
Stop the Insight server as user insight as follows:
$ cd /opt/sonus/ems
$ ./sonusEms stop
In the event you need to change the IP address of your Insight server, perform the following procedure. If desired,
you can change the hostname as well as the IP address.
Perform the following procedure to change the Insight IP address:
If you want to change the hostname of the Insight machine without changing the IP address, do not perform
this procedure. Instead, use Changing the Hostname for Insight without Changing the IP Address.
1. Associate all managed nodes with the intended new IP address (see “Managed Device Association” in the
Administration chapter of the Insight User Guide). Setting the association now allows the server to begin
receiving and processing trap information immediately upon restart.
2. Shut down the Insight management processes.
3. Have your UNIX/Linux System Administrator change the address of the system. If you also want to change
the hostname of your system, have your UNIX/Linux System Administrator change it at this time.
4. As root user, change the IP address of the server, change the IP address in the database tables, and
update the Netcool license information as follows:
a. Enter the following commands:
# ./changeIpAddress.sh -i <ip_address> -d -a
where <ip_address> is the new IP address.

Changing IP address to ‘<ip_address>’.

Do you want to proceed? [y|n]:
b. Respond y. Several messages appear, ending with:
Completed changing IP address to ‘<ip_address>’.

Please refer /opt/sonus/ems/logs/changeIpAddress.log for details.
Please start Sonus Insight server as user 'insight'.
After IP address is changed, ensure that the IP address entry exists or is same as in the /et
c/hosts
6. Start Insight.
7. Disassociate all registered nodes with the old IP address (see “Managed Device Association” in the Insight
Administration chapter of the Insight EMS User Guide).
In the event you need to change the hostname of your Insight server but you are not changing the IP address,
perform the following procedure.
The EMS hostname is limited in length to 64 characters. The hostname can only contain lowercase letters
[a-z] and digits [0-9]. The hostname cannot start with a digit. Special characters including hyphen are not
allowed in hostname.
Perform the following procedure to change the Hostname without changing the Insight IP address:
If you are changing both the IP address and the hostname of the Insight machine, do not perform this
procedure. Instead, use Changing the Insight IP Address.

2. Have your UNIX/Linux System Administrator change the hostname of the system.
3. As root, perform the following, making sure that you enter the current IP address of the server:

a.
# ./changeIpAddress.sh -i <ip_address>
where <ip_address> is the existing IP address.



The new hostname is automatically put into the appropriate files. The IP address of the system is not
changed.
After hostname is changed, ensure that the hostname entry exists or is same as in the /etc
/hosts

This section describes how to perform a complete system backup, and how to perform a system restore using the
backup files.

exp_data_manual.dmp
System Backup
Sonus recommends you to backup the system daily.
1. Log on to the system as a user with root privileges.

2. Run the manualBackup.sh script using the following commands:
to store your backup files. Use a directory that is external to the Insight machine. Use a directory name that
will clearly identify the EMS server that created the backup files. Make a note of the directory path because
you will need it later if you need to restore the system.
The script returns the following text:
The backup results in the creation of three files (backupFiles.tar, dmp files) in the backup directory.

Restoring the System
If you need to restore your Insight system, perform the following tasks:
1. Install Insight on the system by performing the following:

a. Perform Insight Installation. see "Installing Insight Using ISO Image"
b. Perform "Post-Installation Steps".
2. Log in as root.
3. From the backup directory you used for this EMS server in "System Backup", copy the dmp files to the
<ORACLE_BASE>/backup/dump directory. Also, copy the backupFiles.tar file to the /tmp directory.
If the dmp files are copied to <ORACLE_BASE>/backup/dump using an unconventional method, change
the owner and group of the files to Oracle and DBA.
To change the owner and group of files to Oracle and DBA, enter the following commands:
# cd /opt/sonus/ems/conf/jumpstart
# ./emsMigrate.sh
Do you wish to continue [y|Y,n|N] ? y
Type y and press ENTER.
Enter directory for backupFiles.tar:
Enter /tmp and press ENTER.
7. The system displays the following after few minutes:

7.
Enter maximum disk space allowed for fm logs or return to leave unchanged
format: number[M|G]
example: 100M -- sets the value to 100mb
current value: 100M:
Press ENTER for default value or enter a valid digit followed by M to overwrite.
For example, 8M.
[y|Y,n|N] ?
Type y to restore the data (User Activity Logs, PM Stats and TrunkGroup Tables) or type n if you do not want
to restore the data and press ENTER.

Starting and Stopping the Insight Database
The Insight Database should automatically start and stop at system startup and shutdown time respectively.
If you wish to manually start the Insight database use the following instructions:
1. Log in as the user oracle and issue the following commands:
$ sqlplus /nolog
SQL> conn /as sysdba
SQL> startup
SQL> exit
If you wish to manually stop the Insight database use the following instructions:
1. Log in as user insight and shut down the Sonus Insight server on EMS Standalone (SA) using the
following command:

1.
$ sqlplus /nolog
SQL> shutdown immediate
SQL> exit
Checking the Status of the Insight Database
To check the status of the Insight database, perform the following:
1. Log in as oracle user and enter:
$ ps -ef | grep oracle
If the Insight database is running, a list of active oracle processes are displayed.
If the Insight database is not running, no processes are displayed.
Starting and Stopping the Database Listener
The client listener should automatically startup and shutdown with the Insight database. If you need to manually start
or stop the listener, use the following instructions:
1. To manually start the listener, login as oracle and use the following command:
$ lsnrctl start
1. To manually stop the listener, login as oracle and use the following command:
$ lsnrctl stop
Checking the Status of the Database Listener
1. Log in as oracle user and enter:
$ lsnrctl status

If the database listener is running, the status of the listener and the status of database instances will be
displayed.
If the database listener is not running, “no listener” messages will be displayed.
Configuring Netcool
On this page:
When to Perform Netcool Configuration

Netcool Configuration
Starting, Stopping, or Verifying the Netcool Process
Perform Netcool configuration when modifying logging parameters.
Perform the following steps to configure Netcool:
1. Log in as root user.

2. Run the setup script to configure Netcool related components as follows:
# ./netcoolsetup.ksh
This script modifies FM logging parameters.
3. The script prompts you for how much disk space to allocate for FM log files. Enter a value or accept the
default.
4. Start the Netcool processes. See Starting, Stopping, or Verifying the Netcool Process.
Under normal circumstances the Netcool processes start and stop when you start or stop the Insight server. If you
want to start, stop, or check the status of the Netcool processes separately from the Insight server, use the following
commands.
To start the Netcool process, as user insight execute the following commands:
1. Change the directory to /opt/sonus/ems and start the Netcool processes:
$ cd /opt/sonus/ems
$ ./sonusEms start fm
2. To verify the status of Netcool processes, as user insight type:

2.
$ ./sonusEms status fm
Several Netcool components have a delayed startup due to their dependence on the Netcool
database. These processes show “PENDING” status. If processes remain in a “PENDING” state
longer than two minutes after startup, there is a configuration problem.
3. If you need to stop the Netcool processes, as user insight type:
$ cd /opt/sonus/ems
$ ./sonusEms stop fm

The default Netcool object server name is SONUSDB. You can rename the Netcool object server to the desired
name.
To change the Netcool DB name, perform the following the procedure:
1. On EMS server get the netcool DB name from /opt/sonus/netcool/omnibus/db/{DB_NAME}

2. Stop EMS as user insight by running the following command:
$ /opt/sonus/ems/sonusEms stop fm
3. As insight user execute the following script:
Ensure that all services are stopped, before executing the following command.
$ /opt/sonus/ems/conf/netcool_rename_db.ksh
4. System displays the following:
Please Enter Old Object Server name and press [ENTER]
Enter the old DB name which is found in step 1 and press ENTER.
Please Enter New Object Server name and press [ENTER]:
Enter the new object server name and press ENTER.
6.

6. Start EMS as user insight by running the following command:
Limitation
Following are the limitations when changing Netcool Object Server Name:
Avoid using NCO_PA, NCO_GATE and NCO_PROXY as the new Netcool Object Server Name. These are used
only for Internal purpose.
Upgrade operation is not supported with the changed netcool object server name. In order to do so, you need
to first rollback to default netcool object server name “SONUSDB”.

This section provides information about the High-Availability specific administrative tasks. It covers the
following topics:


This section provides information for performing administrative tasks specifically performed on EMS High Availability
(HA) server.
Checking EMS Version

Checking the EMS Server Status
Starting the EMS and Insight Services
Stopping the EMS and Insight Services
EMS Server Backup and Restore
System Backup
Checking EMS Version
# rpm -qa SONSems
Expected output:

SONSems-V09.03.00-R000.x86_64
Checking the EMS Server Status
$ cd /opt/sonus/ems/conf/HA/RAC
$ ./sonusEMS status

---------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
---------------------------------------------------------------------------
Cluster Resources
---------------------------------------------------------------------------
sonus.agent
1 ONLINE ONLINE harare
2 ONLINE ONLINE belgrade
sonus.apacheproxy
sonus.callTraceListener
sonus.databaseCheck
sonus.fmTrapReceiver
sonus.hotDeploy
1 ONLINE OFFLINE
sonus.monitor
sonus.netcoolLicenseManager
sonus.netcoolMount
sonus.objectserver
1 ONLINE OFFLINE STARTING
sonus.owl
sonus.rmtexec
sonus.route
sonus.trapProbe
sonus.vip
sonus.vipv6
1 ONLINE OFFLINE
sonus.warmDeploy
2 ONLINE OFFLINE
In the above output, ems1 is the active system and ems2 is the standby system. ems1 has the various processes
running that are only running on a single server. ems1 also has the sonus.vip and sonus.vipv6 resource. The
following are the list of process names in the status map along with the servers on which they are running:
sonus.agent - The Insight Agent (both servers)

sonus.apacheproxy - Indicates the status of apache proxy server (up/down). It is used to launch EMA

through proxy in EMS.
sonus.callTraceListener - The PSX Call Trace Listener (both servers)
sonus.databaseCheck - Indicates whether the DB is up and ready for connections (both servers)
sonus.fmTrapReceiver - FM Trap Receiver (both servers)
sonus.hotDeploy - The JBoss instance in hot deploy (active) mode (runs only on the active server)
sonus.monitor - An internal monitoring script which looks for issues in the processes managed by
Clusterware and takes action when they are encountered (both servers)
sonus.netcoolLicenseManager - The Netcool License Manager (both servers)
sonus.netcoolMount - the EMS partition mount (contains Netcool DB + PM CSV files, health reports, user
activity logs, etc.) (runs only on the active server)
sonus.objectserver - The Netcool Object Server (runs only on the active server)
sonus.owl - It is a resource monitoring tool which logs the resource usage of various Insight processes.
sonus.rmtexec - The Remote Exec process (both servers)
sonus.route - An internal route used to properly manage the Sonus VIP (runs only on the active server).
This process ensures that all the north bound packets are routed through the Sonus VIP rather than the
public interface of the active server.
sonus.trapProbe - The Sonus Trap Probe (both servers)
sonus.vip - The Sonus VIP (virtual IP address) - in other words, the well-known IP (runs only on the active
server)
sonus.vipv6 - The Sonus IPv6 VIP (virtual IP address) - this is the IPv6 well-known IP. Only appears when
provisioning on an IPv6 enabled system (runs only on the active system).
sonus.warmDeploy - The JBoss instance in warm standby mode on both servers.
Starting the EMS and Insight Services
Occasionally, it may become necessary to start the EMS and Insight services. To do so, use the following
commands:
Start the EMS and Insight services as user insight as follows:
$ ./sonusEMS startAll
Stopping the EMS and Insight Services
Occasionally, it may become necessary to stop the EMS and Insight services. To do so, use the following
commands:
Stop the EMS and Insight services as user insight as follows:
$ ./sonusEMS stopAll
If EMS cannot be stopped or if it is taking a long time to stop EMS then use the sonusEMS stopAll -f command,
to stop EMS forcefully. The sonusEMS stopAll -f command is used, whenever an EMS process indicates a '
FAILED' state while starting.

$ ./sonusEMS stopAll -f
EMS Server Backup and Restore
backup files.
System Backup
System Backup
Sonus recommends you to backup the system daily.

The backup results in the creation of backupFiles.tar and dmp files in the backup directory.
If EMS is successfully upgraded then data prior to upgrade is retained and there is no need to restore the
backup. Restore data is essentially used when upgrade fails.
1. Install Insight on both the EMS HA systems (active and standby) by performing the following:
a. Perform Insight Installation. see "Kickstart the HP G8 Servers ".
b. Configure RAID and Install Oracle Clusterware.
c.

1.

d. Enter the following command to start Insight as user insight:
$ /opt/sonus/ems/conf/HA/RAC/sonusEms startAll
2. Log in as root. From the backup directory you used for this EMS server, copy the following files from the
backup directory on the remote server to the current location (For example, /export/home/backups):
exp_data_manual.dmp


log

This section contains the following high availability (HA) Insight server administrative tasks:
HA Manual Switchover
It may become necessary in a HA system, to initiate a manual switchover from the active to the standby system.
When connectivity is lost to the IBM DS3524, the node which loses connectivity will reboot. This will trigger
a failover if the connectivity is lost on the active node.
Perform the following procedure, to execute a switchover:
1. As user root, enter the following:

The success or failure of the switchover is displayed:
----------------------------------------------------------
'sonus.agent' on 'ems2' : OK
'sonus.fmTrapReceiver' on 'ems2' : OK
'sonus.trapProbe' on 'ems2' : OK
'sonus.netcoolLicenseManager' on 'ems2' : OK
'sonus.rmtexec' on 'ems2' : OK
'sonus.callTraceListener' on 'ems2' : OK
'sonus.databaseCheck' on 'ems2' : OK
'sonus.warmDeploy' on 'ems2' :
OK--------------------------------------------------------------------------------------------
processes on standby appear to be healthy. Initiating relocate
Attempting to stop `sonus.hotDeploy` on member èms1`Stop of `sonus.hotDeploy`
on member èms1` succeeded.
Attempting to stop `sonus.hotDeploy` on member èms1`
Stop of `sonus.hotDeploy` on member èms1` succeeded.
Attempting to stop `sonus.objectserver` on member èms1
Àttempting to stop `sonus.route` on member èms1`Stop of `sonus.objectserver`
on member èms1` succeeded.
Attempting to stop `sonus.netcoolMount` on member èms1`Stop of `sonus.route`
on member èms1` succeeded.Stop of `sonus.netcoolMount` on member èms1`
succeeded.
Attempting to stop `sonus.vip` on member èms1`Stop of `sonus.vip` on member
èms1` succeeded.
Attempting to start `sonus.vip` on member èms2`Start of `sonus.vip` on member
èms2` succeeded.Attempting to start `sonus.netcoolMount` on member
èms2`Start of `sonus.netcoolMount` on member èms2` succeeded.
Attempting to start `sonus.objectserver` on member èms2`
Attempting to start `sonus.route` on member èms2`Start of `sonus.route` on
member èms2` succeeded.Start of `sonus.objectserver` on member èms2`
succeeded.
Attempting to start `sonus.hotDeploy` on member èms2`Start of
`sonus.hotDeploy` on member èms2` succeeded.
Relocate Complete----------------------------------------
2. If the switchover was not successful, contact the Sonus TAC.
Troubleshooting
HA Logs
This section lists the logs and the corresponding location.
haRac.log: Contains information on the start, stop, and status commands being run continuously to monitor
the health of the system. The haRac.log is located at /opt/sonus/ems/logs.
haMonitor.log: Contains output of the Sonus Monitor script, which monitors Clusterware and looks for
irregularities in the system. The haMonitor.log is located at /opt/sonus/ems/
Additional Clusterware log files are stored at /opt/11.2.0/grid/logs/<hostname>.
alert<hostname>.log: Contains high-level alerts from Clusterware - good place to start when debugging
Clusterware errors.
crsd/crsd.log: Contains detailed output from the Cluster Ready Services daemon (crsd): Primarily related to

Clusterware automatically starting and managing processes.
Rebooting an HA server
If both the servers are rebooted simultaneously, then it will take a few minutes for the cluster services to be restored.
It is not recommended to reboot both the servers simultaneously.
If the HA systems get into a state where one of the servers is not properly becoming the active or standby, it is
recommended to reboot only the server that is causing issues and not any other servers. The server can be
rebooted by using the Linux reboot command as the root user.
If the RAID is locked, contact Sonus support to manually unlock the RAID. Because of the risk of dual
mounting the RAID, removing the RAID lock must be done by Sonus support ONLY.
Resetting HA Configuration
If any of the processes show up in the UNKNOWN state after running a sonusEMS stopAll, then you need to reset
the HA configuration. This can be performed by running the following command as the root user:
# /opt/sonus/ems/conf/HA/RAC/hamgmt reset
This will shut down the EMS processes on both servers, delete and re-create the Clusterware configuration, and
then restart the EMS processes.
Taking HA System Out Of Clusterware
If there is a hardware failure or any other failure which causes one of the systems in the HA setup to become
unstable or inoperable, then you can take the system out of service.Run the following command as the root user on
the system that is to be taken out of clusterware.
# /opt/sonus/ems/conf/HA/RAC/hamgmt shutdownNode
Initiating Node shutdown.

Please wait Node has been shutdown
When the node is out of service, there is only one node available, and automatic or manual failover is not
possible.
Run the following command, if you want to bring the node back into service:
# /opt/sonus/ems/conf/HA/RAC/hamgmt startupNode

Initiating Node and EMS services startup.

This may take a while Node has been started.
This will bring the system back into service as the standby.
Adding a New IBM RAID Trap Destination
For adding a new IBM RAID 3524 Trap destination for a HA setup, perform the following steps:

2. Execute the following command on active server to turn ON the SMagent and SMmonitor utilities for initial
chkconfig settings:
# chkconfig SMagent on
# chkconfig SMmonitor on
3. Execute the following command, to send IBM RAID traps to the specified new destination:
In case of EMS HA, specify the well-known IP address.
# SMcli -n <ARRAY NAME> -a trap:public,<IP address>
Example:
#SMcli -n EMSIBMRAID -a trap:public,10.54.58.101
By default the IBM RAID traps are sent to the loopback IP address: 127.0.0.1. To send IBM RAID
Traps to loopback IP address, execute the following command:
# SMcli -a trap public,127.0.0.1 -n emstk1_array

name.
1. On Active server get the netcool DB name from /export/raid/Omnibus/db/{DB_NAME}


3. As root user execute the following script on primary server:
$ /opt/sonus/ems/conf/HA/RAC/AS/netcool_rename_db.ksh

6. As root user execute the following script on secondary server:
# cd <BASE_DIR>/conf/HA/RAC/AS
# ./netcool_rename_db_RAC.sh

# /opt/sonus/ems/conf/HA/RAC/sonusEMS startAll
Limitation


1. Log in as the user oracle on active server and issue the following commands:
$ sqlplus /nolog
SQL> startup
SQL> exit
2. Log in as the user oracle on standby server and issue the following commands to start EMS:
$ sqlplus /nolog
SQL> startup
SQL> exit
3. Start EMS on active and standby servers as user insight, by executing the following command on active
server:
1. Stop EMS on active and standby servers as user insight, by executing the following command on active
server:
2. Log in as the user oracle on standby server and issue the following commands:

$ sqlplus /nolog
SQL> exit
3. Log in as the user oracle on active server and issue the following commands:
$ sqlplus /nolog
SQL> exit
1. Log in as oracle user and enter the following command on active and standby servers to check if oracle
processes are running:
If the Insight database is running, a list of active oracle processes are displayed.
If the Insight database is not running, no processes are displayed.
EMS DR Operations
Table of Contents
Setup
Switchover
Failover
Resume
Teardown
Status
Trap Notification
EMS Logs
Overview on EMS Disaster Recovery (DR) Configuration

The EMS Disaster Recovery (DR) configuration provides a method of deploying an additional EMS system in a
location geographically separate from your primary EMS installation for use in the event your Source (Primary DB)
EMS system becomes disabled. Through the use of a database replication mechanism, the Target (Standby DB)
system receives periodic updates from the source (production) system, keeping EMS configuration synchronized.
The EMS application as a whole is not running on the target system. However, the target system does receive the
same traps that are received by the source system. The target system cannot be used as a functioning EMS until
you switchover from the source and target or failover from the source to the target.
The Sonus EMS DR solution uses Data Guard, employing a Physical standby database with Maximum performance
protection mode.
The physical standby (Target) database is an identical copy of the primary (Source) database. The physical standby
database has on-disk database structures that are identical to the primary database on a block-for-block basis. The
database schema, including indexes, are the same. A physical standby database is kept synchronized with the
primary database by recovering the redo data received from the primary database.
The Maximum performance protection mode provides the highest level of data protection that is possible without
affecting the performance of the primary database. This is accomplished by allowing a transaction to commit as
soon as the redo data needed to recover that transaction is written to the local online redo log. The primary
database’s redo data stream is also written to the standby database, but that redo stream is written asynchronously
with respect to the commitment of the transactions that create the redo data.
For the DR setup, if the ems.keystore password is changed on one EMS (either source / target), then it
needs to be manually changed on the other EMS (either source / target). If it is not changed, the other
EMS will not be able to open the ems.keystore at all and all SSL connections will fail. In other words, the
ems.keystore passwords must be kept the same on both EMS (source and target) at all times.
Setup
The Setup operation configures the Source (Primary DB) and Target (Standby DB) sites for replication, backs up the
Primary database, restores it on the Standby site, and initiates the replication process. This operation is performed
to initially setup a replicated environment, or after a previous DR setup has been torn down. During this step, some
EMS configuration (password files, managed node info) files are also synced from the source to target. Before
performing this procedure, both the source and target sites must have EMS installed.
Setting up DR is a service-impacting operation. The source EMS is brought down for the initial part of the
setup process. The target EMS database is overwritten with source database, as part of DR setup.
Prerequisites
EMS should be up and running on the intended Source and Target sites.
Both sites should have the same EMS version running.
Verify the network connectivity between the 4 nodes (of 2 sites) with: Source and Target sites. Ensure that
the ping times between sites should be 225 millis or lower.
Ensure that the insight system user passwords are same on both the Source and Target EMS sites.
Setting up DR
Perform the following procedure to setup DR. Run the manageDR command on the intended source node (if EMS
HA, run on node 1 of source site).
Press y when the command output asks "Do you want to continue with setting up DR? [y|n]:"

During DR 'setup' as well as 'resume' steps, the Source database is backed up and restored on the Target
system. This may take some time (1 hour or longer) depending on how big the database is, and how fast is
the network connection speed between the DR sites. You should wait for the entire setup operation to
complete.
1. Run the following command on the Source.
[root]# /opt/sonus/ems/conf/DR/manageDR setup
This step will setup DR with the current host emshp5 as the DR source.
'insight' Linux system user password should be same on all systems.
You will be prompted for DR target node IPv4 address.
[ WARNING ] Database on DR target node will be overwritten and brought in sync
with this local database
Do you want to continue with setting up DR? [y|n]: y
1. [17:57:00] emshp5# Running pre-setup checks

Please specify the IPv4 address of the remote DR TARGET node: 10.155.75.17
2. [17:57:04] emshp5# Checking connection to DR peer node

10.155.75.17
3. [17:57:04] emshp5# Pinging peer IP 10.155.75.17
4. [17:57:04] emshp5# Checking insight@10.155.75.17 user equivalence
5. [17:57:04] emshp5# Establishing insight@10.155.75.17 [] user
equivalence
.............................................
........<Command output cut for brevity>.....
.............................................
133. [18:04:06] emshp4$ Setting up (add) sync files cron job

134. [18:04:06] emshp4$ Completed sync files cron job setup.
135. [18:04:06] emshp5# Completed sync files cron job setup.
136. [18:04:06] emshp5# Successfully synched files to DR peer active
IP
137. [18:04:06] emshp5# Completed DR setup.
[root]#
Switchover
Switchover is a planned role reversal between the Source (Primary DB) and the Target (Standby DB) to avoid
downtime during scheduled maintenance on the Source (Primary DB) or to test readiness for future role transitions.
A switchover guarantees no data loss. During switchover, the Source system transitions to a Target and the Target
system transitions to a Source.
Prerequisites
Login to Source EMS Fault Manager (FM) GUI and ensure that there are no recent recurring DR related
traps, before you perform a switchover.
Run 'manageDR status' on the Source node. For details, see Status. Verify that the status output displays
that replication is working correctly.
Check the EMS server status on both Source & Target sites. For details, see Checking the Insight Server
Status. Verify that all required EMS processes are online. Only a subset of EMS processes run on DR target
site as there is no read/write access to the local standby database.

Performing a Switchover
Run the 'manageDR switchover' command on the source node (if EMS HA, run on node 1 of source site).
Press 'y' when the command output prompts you a confirmation message "Do you want to continue with
DR switchover? [y|n]:"
1. On the Insight Node1, enter the following commands:
[root]# /opt/sonus/ems/conf/DR/manageDR switchover
This step will switchover DR from this node emshp5 [10.155.75.13] to remote
node emshp4 [10.155.75.17]
Do you want to continue with DR switchover? [y|n]: y
1. [18:17:50] emshp5# Running pre-switchover checks

10.155.75.17
.............................................
.............................................
42. [18:19:45] emshp4$ Performing EMS server start. Please wait...

43. [18:21:38] emshp4$ Completed performing EMS process start
44. [18:21:38] emshp5# Successfully completed peer EMS emshp4
[10.155.75.17] startup in SOURCE mode.
45. [18:21:38] emshp5# Completed DR switchover.
After successfully completing the switchover, it is a recommended to check the DR replication status
(manageDR status). For details, refer Status on the new Source node, after about 10 mins, to ensure that the
data is replicating successfully.
Failover
A failover is an unplanned operation performed when the source site goes offline for some reason and you need to
promote the target site into a fully functional EMS. Run the 'manageDR failover' command on the target node (if
EMS HA, run on node 1 of target site), when the source goes offline. A manual failover is performed when the
Source (Primary DB) fails and the Target (Standby DB) and target system is transitioned to take over the new
Source, allowing business operations to continue. The user must run the failover procedure in order for a failover to
take place.
Performing a failover operation may involve some data loss because of the inability to extract the most
recent database changes from the down Source (Primary DB) site.
After the old Source site comes back online at a later time, you should perform a resume operation "manageDR
resume". For details, see Resume. This will convert the old Source into a new Target role.
Press y when the command output asks "Do you want to continue with DR failover? [y|n]:".

1. On the Insight Node1 of target site, enter the following commands:
[root]# /opt/sonus/ems/conf/DR/manageDR failover
This step will failover DR from remote node emshp4 [10.155.75.17] to this
local node emshp5 [10.155.75.13]
Do you want to continue with DR failover? [y|n]: y
1. [20:27:34] emshp5# Running pre-failover checks

2. [20:27:34] emshp5# Calling rep_failover script on host emshp5
Performing sanity checks ................................................ (ok)
Disabling replication monitoring locally ................................ (ok)
.............................................
.............................................
11. [20:30:07] emshp5# Completed performing EMS process start

12. [20:30:07] emshp5# Successfully configured this system as DR
SOURCE
13. [20:30:07] emshp5# NOTE: Run 'manageDR resume' on this host when
DR peer system is back online.
14. [20:30:07] emshp5# Completed DR failover.
[root]#
After the old source (now target) site comes back, perform the resume operation, to sync up that site's
database with the current source site.
Resume
Run the resume operation to perform the following tasks:
To re-sync the previous Source EMS site after a failover has been invoked. Perform the resume operation on
the same host as the manageDR failover was run from earlier.
Resume operation should only be performed after the EMS server on the previous source (new target) is up
and running.
To re-sync a Target EMS site that has become out-of-sync with the Source because of an extended outage.
The resume procedure does not involve any downtime and the source EMS server remains up and running
while the resume procedure is performed.
Press 'y' when the command output prompts a confirmation message "Do you want to continue with
resume of DR replication? [y|n]:"
1. Perform the resume operation on the new source site as follows:

[root]# /opt/sonus/ems/conf/DR/manageDR resume
This step will resume DR with the current host emshp5 as the DR source.
Performing resume (sync) operation after a previous failover.
Following tasks will be attempted:
- Synchronize the target node emshp4 with the current node.
Do you want to continue with resume of DR replication? [y|n]: y
1. [20:51:16] emshp5# Running pre-resume checks
10.155.75.17
5. [20:51:16] emshp5# Completed user equivalence setup to DR peer
emshp4
.............................................
.............................................
Performing sanity checks ................................................ (ok)

Checking log_archive_dest_state_2 parameter setting .....................
(set)
Deleting backup ......................................................... (ok)
Removing transient files ................................................ (ok)
Enabling replication monitoring on emshp5 ............................... (ok)
Completed successfully. See /opt/oracle/orarepl/SIDB/logs/rep_sync3.64383.log
for details.
53. [20:53:21] emshp5# Finished calling rep_sync3 script on host
emshp5
54. [20:53:21] emshp5# Completed Standby database configuration
steps for sync
55. [20:53:21] emshp5# Completed DR replication resume.
2. After successfully completing the resume operation, it may take 5-10 minutes for redo logs to start getting
transferred and applied.
Verify the replication status ("Status") and ensure that replication is resumed.
3. If you have just performed 'resume' operation and that was a result of a previous failover, and you are using
IAS, then this additional step is required:
After it is verified on the new source node that replication is working successfully, run the IAS procedure.
Teardown
This procedure will uninstall DR and convert the DR setup into 2 separate non-replicated systems, with no
replication relation (source/target) between them.
Teardown procedure is usually only required:
If you do not want DR setup anymore.

If you have a Linux SA DR setup and upgrading or migrating to a newer EMS version. DR would need to be
setup back again after the upgrade completes.
Press 'y', when the command output prompts you a confirmation message "Do you want to
continue with DR teardown? [y|n]:"

1. Run the following command on the source site node 1 as root user.
[root]# /opt/sonus/ems/conf/DR/manageDR teardown
This step will teardown DR from this node emshp5 [10.155.75.13] to remote node
emshp4 [10.155.75.17]
Do you want to continue with DR teardown? [y|n]: y
1. [21:22:07] emshp5# Running pre-teardown checks

10.155.75.17
5. [21:22:07] emshp5# Completed user equivalence setup to DR peer
emshp4
.............................................
.............................................
68. [21:27:51] emshp5# Generating key updater (remove) script

69. [21:27:51] emshp5# Transferring script to peer 10.155.75.17
70. [21:27:52] emshp5# Updating auth key file entries (remove) on
peer 10.155.75.17
71. [21:27:52] emshp5# Completed insight user equivalence teardown to
peer host 10.155.75.17
72. [21:27:52] emshp5# Completed DR teardown.
[root]#
Status
Current status of DR replication can be checked by running the 'manageDR status' command. Each set of
changes is displayed in a single line, and has a sequence number and an associated timestamp when copy or apply
was done. Threads 1 and 2 represent the node 1 and node 2 respectively. Replication activity over the last 1 hour is
shown in the output of 'status' command.
Run the 'manageDR status' command on the source node (if EMS HA, run on node 1 of source site).
1. Run the following command on the source site node 1 as root user.
a. Before performing a switchover, ensure that DR setup has completed. You can identify, DR setup
completion by executing the command manageDR status. The last column 'Applied' of the
command output must display 'YES' for all the rows, except the last row, which displays 'NO'.
The following command output indicates that DR replication is still under-progress, as the multiple
rows show 'NO' as status in 'Applied' column.
root@midas ~]# /opt/sonus/ems/conf/DR/manageDR status

1. [18:50:36] midas# Running pre-status checks
2. [18:50:36] midas# Checking connection to DR peer node
10.54.159.37
3. [18:50:36] midas# Pinging peer IP 10.54.159.37
4. [18:50:36] midas# Checking insight@10.54.159.37 user
equivalence...

5. [18:50:37] midas# Checking connection to DR peer secondary
node 10.54.159.36
equivalence...
8. [18:50:37] midas# Verifying connections from node
10.54.159.49
9. [18:50:39] miranda$ Checking connection to DR peer node
10.54.159.37
10. [18:50:39] miranda$ Pinging peer IP 10.54.159.37
11. [18:50:39] miranda$ Checking insight@10.54.159.37 user
equivalence...
12. [18:50:39] miranda$ Checking connection to DR peer secondary
node 10.54.159.36
equivalence...
15. [18:50:40] miranda$ Completed establishing password-less
connections to DR peer nodes.
16. [18:50:39] midas# Finished conn setup to DR peer from node
10.54.159.49
17. [18:50:39] midas# Completed establishing password-less
18. [18:50:39] midas# Printing DR replication status on this
host midas
Configuration:
Source Cluster: midas miranda
Target Cluster: 10.54.159.37 10.54.159.36
Archive Log Activity Over the Past 1 Hours
Thread# Sequence# Generated on Source Copied to Target
---------- ---------- -------------------- --------------------
2 38 2014-08-19 17:54:40 2014-08-19 18:10:04
1 55 2014-08-19 17:54:52 2014-08-19 18:04:47
2 39 2014-08-19 17:59:40 2014-08-19 18:10:05
1 56 2014-08-19 17:59:49 2014-08-19 18:04:47
2 40 2014-08-19 18:04:41 2014-08-19 18:10:05
1 57 2014-08-19 18:04:50 2014-08-19 18:04:50
2 41 2014-08-19 18:09:41 2014-08-19 18:09:43
1 58 2014-08-19 18:09:50 2014-08-19 18:09:50
2 42 2014-08-19 18:14:39 2014-08-19 18:14:39
1 59 2014-08-19 18:14:50 2014-08-19 18:14:50
2 43 2014-08-19 18:19:39 2014-08-19 18:19:40
1 60 2014-08-19 18:19:51 2014-08-19 18:19:51
2 44 2014-08-19 18:24:40 2014-08-19 18:24:40
1 61 2014-08-19 18:24:48 2014-08-19 18:24:48
2 45 2014-08-19 18:29:40 2014-08-19 18:29:40
1 62 2014-08-19 18:29:49 2014-08-19 18:29:49
2 46 2014-08-19 18:34:41 2014-08-19 18:34:41
1 63 2014-08-19 18:34:49 2014-08-19 18:34:49
2 47 2014-08-19 18:39:41 2014-08-19 18:39:41
1 64 2014-08-19 18:39:50 2014-08-19 18:39:50
2 48 2014-08-19 18:44:42 not copied
1 65 2014-08-19 18:44:50 2014-08-19 18:44:50
2 49 2014-08-19 18:49:39 not copied
1 66 2014-08-19 18:49:51 2014-08-19 18:49:51
Status of Archive Log Destination on the Target: VALID
19. [18:50:39] midas# Printing DR replication status on DR
peer 10.54.159.37
Configuration:
Source Cluster: 10.54.159.48 10.54.159.49
Target Cluster: bourbon martini
Thread# Sequence# Received on Target Applied

---------- ---------- ------------------------ ---------
1 54 2014-08-19 18:04:47 YES
1 55 2014-08-19 18:04:47 YES
1 56 2014-08-19 18:04:47 YES
1 57 2014-08-19 18:04:50 YES
2 41 2014-08-19 18:09:42 YES
1 58 2014-08-19 18:09:50 YES
2 37 2014-08-19 18:10:03 YES
2 38 2014-08-19 18:10:03 YES
2 39 2014-08-19 18:10:04 YES
2 40 2014-08-19 18:10:04 YES
2 42 2014-08-19 18:14:38 YES
1 59 2014-08-19 18:14:51 YES
2 43 2014-08-19 18:19:39 YES
1 60 2014-08-19 18:19:51 YES
2 44 2014-08-19 18:24:39 YES
1 61 2014-08-19 18:24:48 YES
2 45 2014-08-19 18:29:39 YES
1 62 2014-08-19 18:29:49 YES
2 46 2014-08-19 18:34:40 YES
1 63 2014-08-19 18:34:49 YES
2 47 2014-08-19 18:39:40 YES
1 64 2014-08-19 18:39:50 NO

1 65 2014-08-19 18:44:50 NO
1 66 2014-08-19 18:49:51 NO
If DR Setup has not completed, you must not perform the switch-over. Wait for DR setup to
complete and only perform a switchover after you see the status as 'YES' for all rows, except
the last row in the 'Applied' column.
b. The following example indicates successful DR setup, as it can be seen that ' APPLIED' status is 'YES'
for all rows, except the last row:
[root@midas ~]# /opt/sonus/ems/conf/DR/manageDR status

1. [19:17:56] midas# Running pre-status checks
2. [19:17:56] midas# Checking connection to DR peer node
10.54.159.37
equivalence...
5. [19:17:56] midas# Checking connection to DR peer secondary
node 10.54.159.36
equivalence...
8. [19:17:57] midas# Verifying connections from node
10.54.159.49
9. [19:17:58] miranda$ Checking connection to DR peer node
10.54.159.37
equivalence...
12. [19:17:58] miranda$ Checking connection to DR peer secondary
node 10.54.159.36
equivalence...
15. [19:17:59] miranda$ Completed establishing password-less
9. [19:17:58] midas# Finished conn setup to DR peer from node
10.54.159.49
10. [19:17:58] midas# Completed establishing password-less
11. [19:17:58] midas# Printing DR replication status on this
host midas
Configuration:
Source Cluster: midas miranda
Target Cluster: 10.54.159.37 10.54.159.36
Thread# Sequence# Generated on Source Copied to Target
---------- ---------- -------------------- --------------------
2 43 2014-08-19 18:19:39 2014-08-19 18:19:40
1 60 2014-08-19 18:19:51 2014-08-19 18:19:51
2 44 2014-08-19 18:24:40 2014-08-19 18:24:40
1 61 2014-08-19 18:24:48 2014-08-19 18:24:48
2 45 2014-08-19 18:29:40 2014-08-19 18:29:40
1 62 2014-08-19 18:29:49 2014-08-19 18:29:49
2 46 2014-08-19 18:34:41 2014-08-19 18:34:41
1 63 2014-08-19 18:34:49 2014-08-19 18:34:49
2 47 2014-08-19 18:39:41 2014-08-19 18:39:41
1 64 2014-08-19 18:39:50 2014-08-19 18:39:50
2 48 2014-08-19 18:44:42 2014-08-19 18:52:45

1 65 2014-08-19 18:44:50 2014-08-19 18:44:50
2 49 2014-08-19 18:49:39 2014-08-19 18:52:47
1 66 2014-08-19 18:49:51 2014-08-19 18:49:51
1 67 2014-08-19 18:52:51 2014-08-19 18:52:51
2 50 2014-08-19 18:54:39 2014-08-19 18:57:43
1 68 2014-08-19 18:56:15 2014-08-19 18:56:15
2 51 2014-08-19 18:59:40 2014-08-19 18:59:40
1 69 2014-08-19 19:01:13 2014-08-19 19:01:13
2 52 2014-08-19 19:04:40 2014-08-19 19:04:40
1 70 2014-08-19 19:06:13 2014-08-19 19:06:13
2 53 2014-08-19 19:09:41 2014-08-19 19:09:41
1 71 2014-08-19 19:11:13 2014-08-19 19:11:13
2 54 2014-08-19 19:14:41 2014-08-19 19:14:41
1 72 2014-08-19 19:16:14 2014-08-19 19:16:14
Status of Archive Log Destination on the Target: VALID
12. [19:17:58] midas# Printing DR replication status on DR
peer 10.54.159.37
Configuration:
Source Cluster: 10.54.159.48 10.54.159.49
Target Cluster: bourbon martini
Thread# Sequence# Received on Target Applied
---------- ---------- ------------------------ ---------
2 43 2014-08-19 18:19:39 YES
1 60 2014-08-19 18:19:51 YES
2 44 2014-08-19 18:24:39 YES
1 61 2014-08-19 18:24:48 YES
2 45 2014-08-19 18:29:39 YES
1 62 2014-08-19 18:29:49 YES
2 46 2014-08-19 18:34:40 YES
1 63 2014-08-19 18:34:49 YES
2 47 2014-08-19 18:39:40 YES
1 64 2014-08-19 18:39:50 YES
1 65 2014-08-19 18:44:50 YES
1 66 2014-08-19 18:49:51 YES
2 48 2014-08-19 18:52:44 YES
2 49 2014-08-19 18:52:46 YES
1 67 2014-08-19 18:52:51 YES
1 68 2014-08-19 18:56:15 YES
2 50 2014-08-19 18:57:42 YES
2 51 2014-08-19 18:59:39 YES
1 69 2014-08-19 19:01:13 YES
2 52 2014-08-19 19:04:39 YES
1 70 2014-08-19 19:06:13 YES
2 53 2014-08-19 19:09:40 YES

1 71 2014-08-19 19:11:14 YES
2 54 2014-08-19 19:14:40 YES
1 72 2014-08-19 19:16:14 NO
Trap Notification
EMS DR setup supports following trap notifications:
sonusEmsDbDrRepOutOfSyncNotification: Sent when redo logs are not being synced correctly
between source and target.
sonusEmsDbDrErrorNotification: Sent when either source or target database instance is down.
sonusEmsDbDrRepConnectFailNotification: Sent when there is a connectivity issue between source
and target.
Additional details about these trap notifications are available in the Alarm Troubleshooting guide. (see “Disaster
Recovery” section in Insight Alarm Troubleshooting page)
EMS Logs
Logging
Log output from manageDR script goes to /opt/sonus/ems/logs/manageDR.log. This log file gets written on
both source and target sites. Subsequent execution of the manageDR script append to this log file. In addition,
manageDR script calls other internal lower level replication scripts (for example, rep_status). Output from these
scripts, as well as their log files, can be viewed on the console output of manageDR run. These scripts write log
output to files under the /opt/oracle/orarepl/SIDB/logs directory.
Certain EMS configuration files (password, node information etc.) are kept in sync between the source and target via
a syncFiles.sh cron job which uses rsync to keep the text files in sync between the sites. This syncFiles.sh
script writes log output to /opt/sonus/ems/logs/syncFiles.log file. For EMS SA, the log output is written to
/opt/oracle/orarepl/SIDB/logs directory. For EMS HA, this log directory is
/opt/oracle/orarepl/SIDB0[1|2]/logs.
Table of Contents
DR Configuration
About This Document

This document provides a condensed version of the instructions to install a Sonus EMS system running on HP
DL380 G8 servers for EMS Standalone (SA) and High-Availability (HA), and to configure a DR pair of EMS HA
systems.

Related Documentation
For complete installation instructions, refer the following table which provides information related to the tasks and
respective EMS documents to be referred for additional information.
Table 30: Related Documentation
Tasks EMS Documentation Reference Guide
EMS Standalone Installation Installing EMS SA
EMS HA Installation Installing EMS HA
Setting-up DR 1. Install EMS SA or EMS HA

2. Setup DR
Glossary and Term Definitions

Table 31: Glossary and Term Definitions
Abbreviations Definitions
SA - Standalone A Standalone (SA) EMS system, consisting of a single EMS application server.
HA – High Availability A High Availability (HA) EMS system, consisting of two EMS application servers (Active and
Standby), with a single shared RAID system, co-located at the same geographical site.
DR - Disaster Recovery A Disaster Recovery (DR) EMS system, consisting of two geographically separated EMS
Systems (Source and Target), either both Standalone or both High Availability.
iLO – Integrated An iLO provides out-of-band management facility.

Lights-Out Management
Engine
port
RAC – Real Application Oracle Real Application Cluster (RAC) provides software for clustering and high-availability in
Cluster an Oracle database environment.
RAID – Redundant Array RAID is a storage technology that provides the ability to combine multiple disks into logical units
of Independent Disks for data redundancy and performance enhancement.
Active and Standby Active and Standby terms designate two servers in a HA deployment. The Active server is the
one which currently processing the services, while Standby server acts as a standby.
In case, if the Active server fails, the Standby takes over and provides computing services to
clients. Also, the role of Standby is changed to an Active server after a failover.

2.

links in the WL9.3 software bundle to download the files.
For the list of files you need to download, refer the relevant section matching your deployment setup (SA or
HA):
Downloading Installation Files for SA

Downloading Installation Files for HA
This section covers the tasks involved in EMS SA installation.
Prerequisites
Files to Download
Installing EMS Standalone (SA) using iLO
Verifying the EMS Installation
Post-Installation Checks
Prerequisites
The prerequisites for performing EMS SA installation are:
All servers and hardware must be installed and powered up, all network connections must be established,
and iLO advance license must be installed, before performing installation.
Before performing the EMS SA installation, collect the information pertaining to the IP, Subnet mask, and
Gateway. The networking details you need to collect are available in the section Information Required Prior to
Installing Insight SA.
Files to Download
The following table provides list of files to be downloaded for ISO installation.
ISO Upgrade Files
ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso
Firmware file
Installing EMS Standalone (SA) using iLO
To install EMS SA using iLO, perform the following steps:
1. Copy the ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso to the local desktop.

2. Launch the remote console.
3. Mount the virtual disk as CD-ROM by selecting Virtual Drives and select the Image File option.
4.

4. Reset the server, press F11 (Boot Menu) and select option 1 (One Time Boot to CD-ROM).
5. Select 1 for install option "EMS Install using Monitor and Keyboard or Remote Console".
6. Complete Red Hat Linux installation.
7. After reboot, perform Network Configuration (Hostname, IP, Timezone, DNS, and TimeServer).
8. Change the boot order to Hard Drive and save the settings.
9. Change the root password after reboot.
10. Run /opt/sonus/ems/conf/configureJumpstart.sh script.
11. As insight user, execute the following command to start insight application:
$ ./sonusEms start
The EMS ISO Installation takes approximately 1 hour 20 to 1 hour 30 minutes to complete.
To verify the EMS installation, execute the following command after the Linux SA EMS installation is complete.
If logged-in as 'root' user, execute the following command:
# /opt/sonus/ems/sonusEms status
If logged-in as 'insight' user, execute the following command:
$ ./sonusEms status
Post-Installation Checks
After completing the EMS installation, ensure that the PSX manager GUI, iLO firmware version, and Device
Manager are upgraded to the latest. For more information, refer Performing Post-installation Tasks on EMS SA.
This section covers the tasks involved in EMS HA installation.
Prerequisites
Installing EMS High Availability (HA) using iLO
Installing RAC
Installing the Oracle Clusterware and EMS Application
Post Installation Checks
Upgrading HP iLO Firmware Version
Upgrading IBM Storwize V3700 Firmware Version
Prerequisites

The prerequisites for performing EMS HA installation are:
All servers and hardware must be installed and powered up, all network connections must be established,
and iLO advance license must be installed, before performing installation.
Identify and finalize the IBM RAID type (IBM DS3524 or IBM V3700) and setup the hardware, cable, and
network connection. For more details, refer Hardware Installation and Setup.
Before performing the EMS HA installation, collect the information pertaining to the IP, Subnet mask,
Gateway. The networking details you need to collect are available in the section Information Required Prior to
Installing Insight HA .
Configure RAID on local disks.
Installing EMS High Availability (HA) using iLO
To install EMS HA using iLO, perform the following steps:
Note: Steps 3 to 7 must be performed on both the servers (Active and Standby).
1. Copy the emsrac-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso to the local desktop.

Make a second copy of the .iso on the local desktop to support parallel installation of Active and Standby
servers.
2. Launch the remote console, one for the Active server and one for the Standby server.
3. Mount the virtual disk as CD-ROM by selecting Virtual Drives and select the Image File option.
4. Reset the Active and Standby servers.
5. Select 1 for install option "EMSRAC Install using Monitor and Keyboard or Remote Console".
6. Select the Time Zone, wait for the installation to complete, and then fill the required network details (Device
configuration and DNS configuration).
7. Change the root password after reboot.
For detailed steps, refer Kickstart the HP G8 Servers.
Installing RAC
The following steps are executed only on the Active EMS server, but also performs operations on the Standby
server, as well.
To install RAC, perform the following steps:
1. Change the directory using the command cd /export/home/pkg/.
2. Create a backup of the configuration template file (rac.conf_3524.template or

rac.conf_3700.template) file, for future reference.
a. If using IBM DS3524 RAID, run the following command, to create a backup of
rac.conf_3524.template.
# cp rac.conf_3524.template <anyName>3524.rac.conf
OR
b.

b. If using IBM V3700 RAID, run the following command, to create a backup of
rac.conf_3700.template.
# cp rac.conf_3700.template <anyName>3700.rac.conf
3. Based on IBM RAID you are planning to use (IBM DS3524 or IBM V3700), update the respective
configuration template file (rac.conf_3524.template or rac.conf_3700.template) with parameters
matching your network setup using vi editor. The information pertaining to network details you need to collect
are available in Information Required Prior to Installing Insight HA.
4. Configure RAID and network bonding for respective IBM RAID being used as follows:
a. If you are using IBM DS3524 RAID, execute the following command:
# ./RACinstall_1 <anyName>3524.rac.conf
OR
b. If you are using IBM V3700 RAID, execute the following command:
# ./RACinstall_1 <anyName>3700.rac.conf
The ./RACinstall_1 command takes approximately 15 to 20 minutes to complete.
5. Both servers are automatically rebooted.
Installing the Oracle Clusterware and EMS Application
The following steps are executed only on the Active EMS Server. To install the Oracle Cluster and EMS Application,
perform the following steps:
1. Change the directory, using the following command:
2. Execute the following command to install the EMS application
# ./EMSRACinstall
The ./EMSRACinstall command takes approximately 1 hour - 1 hour 10 minutes to complete.
The logs can be found at /var/sadm/install/logs/*

To verify the EMS installation, execute the following command after the Linux HA EMS installation is complete.
# /opt/sonus/ems/conf/HA/RAC/sonusEMS status
You should see a message with all the EMS services running on Active and Standby servers.
Post Installation Checks
The following firmware-related checks must be performed after completing the EMS Application installation.
Upgrading HP iLO Firmware Version
do the following:

Installing EMS V09.03.00 overrides the device manager (DM) on the existing EMS and provides support for
SBC 4.0 and prior releases. For more information on Device Manager, see the SBC Manager section of the
Insight User Guide.
For information on additional post-installation tasks (non-mandatory), see Performing Post-Installation or

Upgrade Tasks.
Upgrading IBM Storwize V3700 Firmware Version
Ensure that the IBM V3700 RAID firmware version is upgraded to the latest. In case, you do not have the latest IBM
V3700 firmware version, upgrade it to the latest version. For more information about latest IBM V3700 firmware
version and upgrading the IBM V3700 firmware version, refer the IBM Storwize V3700 Firmware Upgrade Quick
Start section.
DR Configuration
This section covers the EMS DR configuration.
Prerequisites
Ensure that following prerequisites are met, before setting-up DR configuration:
1. EMS SA or HA installation should be completed on both the Source and Target DR sites.
2. The EMS should be running on the Source and Target systems.
3. The Target should be accessible from the Source EMS systems, and vice versa.

Configuring the DR Systems
For configuring DR for Standalone (SA) EMS system, the following steps are executed only on the DR Source SA
EMS System. If you are configuring DR for High Availability (HA) EMS systems, the following steps are executed
only on the DR Source Active EMS system.
To setup DR, perform the following steps:
1. Change the path to /opt/sonus/ems/conf/DR by executing following command:
2. Execute the ./manageDR setup command to setup DR:
# ./manageDR setup
3. A confirmation message to setup DR, is displayed. Press y when asked "Do you want to continue
with setting up DR? [y|n]:"
4. For SA DR setup, enter the Target IP and for HA DR setup, enter the Target Active IP when asked "Please
specify the IPv4 Address of Node 1 of the remote DR TARGET cluster".
The DR Setup configures the Source and Target clusters for replication, backs up the Active database,
restores it on the Standby cluster, and initiates the replication process.
If you want to verify DR setup, with EMS HA systems, the following steps are executed only on the DR Source EMS
Active System. For verifying DR setup, with EMS SA system, the following steps are executed only on DR source
SA system.
To verify the DR configuration, perform the following steps:
1. Ensure that the directory path is /opt/sonus/ems/conf/DR. If not, change the path, using following
command:

2. Execute the command ./manageDR status to verify the DR configuration.
# ./manageDR status
The system displays a message showing the system configuration details.

Table of Contents
EMS DR Upgrade
About This Document

This document provides a condensed version of the instructions to upgrade a Sonus EMS system running on HP
DL380 G8 servers for EMS Standalone (SA), High-Availability (HA), and DR setups.
Related Documentation
For complete upgrade instructions, refer the following table which provides information related to the tasks and
respective EMS documents to be referred for additional information.
Table 33: Related Documentation
Tasks EMS Documentation Reference Guide
EMS Standalone Upgrade Upgrading EMS SA
EMS HA Upgrade Upgrading EMS HA
EMS DR Upgrade Standalone Upgrade for DR Setup
HA Upgrade for DR Setup
EMS DR Operations
Glossary and Term Definitions

Table 34: Glossary and Term Definitions
Abbreviations Definitions
SA - Standalone A Standalone (SA) EMS system, consisting of a single EMS application server.
HA – High Availability A High Availability (HA) EMS system, consisting of two EMS application servers (Active and
Standby), with a single shared RAID system, co-located at the same geographical site.
DR - Disaster Recovery A Disaster Recovery (DR) EMS system, consisting of two geographically separated EMS
Systems (Source and Target), either both Standalone or both High Availability.
iLO – Integrated An iLO provides out-of-band management facility.

Lights-Out Management
Engine
port
RAC – Real Application Oracle Real Application Cluster (RAC) provides software for clustering and high-availability in an
Cluster Oracle database environment.
RAID – Redundant RAID is a storage technology that provides the ability to combine multiple disks into logical units
Array of Independent for data redundancy and performance enhancement.
Disks
Active and Standby Active and Standby terms designate two servers in a HA deployment. The Active server is the
one which is currently processing the services, while Standby server acts as a standby.
In case, if the Active server fails, the Standby takes over and provides computing services to
clients. Also, the role of Standby is changed to an Active server after a failover.
Upgrading Insight - An Overview

Prerequisites
Sample Standalone Configuration File
Firmware Upgrade
Upgrading Insight - An Overview
For upgrading from a previous EMS software release to V09.03.00, you must upgrade using the ISO based upgrade
method. The ISO based upgrade method enables you to upgrade the Operating System, database, apart from
upgrading the EMS Software Application.

Table 35: Examples Depicting Selection of Upgrade Method
V08.04.07 V09.03.00 ISO Upgrade
V09.00.00 V09.03.00 ISO Upgrade
V09.01.00 V09.03.00 ISO Upgrade
V09.03.00 V09.03.01 ISO Upgrade
The Standalone upgrade procedure has been simplified to a great extent. Execute the script upgradeEMS.sh and
point to the path of the ISO. It also provides an option to generate the ems_upgrade.conf configuration file,
which has upgrade and backup parameters list, that can be changed.
Prerequisites
This section covers the tasks involved in EMS SA Upgrade.
The EMS upgrade procedure must be executed as superuser " root ".
The following table provides list of files to be downloaded for ISO upgrade.
ISO Upgrade Files
ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso
upgradeEMS.sh
Firmware file

For Example:
1. Login to Salesforce customer portal using your Sonus provided login, and click SOFTWARE DOWNLOADS .
links in the WL9.3 software bundle to download the files.
For the list of files you need to download, refer the following section.
Download the following files from the Sonus Salesforce Customer Portal to perform the Insight Upgrade using an
ISO Image.
Required Usage Download Procedure

/
Not
Required

Required The ISO file
for ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso
upgrading contains the EMS 9.3.0 application, OS, and database Perform the following steps to download ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso and
to updates. This ISO file is used for both INPLACE and upgradeEMS.sh files:
V09.03.00 KICKSTART upgrade types.
The upgradeEMS.sh file is a script which is required to Enter the <NEW_EMS_VERSION> directory name as the EMS release number
perform ISO upgrade. The upgradeEMS.sh file performs
to which you are upgrading. For example, to upgrade to 9.3 release, instead of
all the necessary tasks such as system checks, create
<NEW_EMS_VERSION> specify 9.3 as directory name. The directory <NEW_E
backup of configuration, upgrade OS, Database and
MS_VERSION> where you are downloading the file, must be empty and must
EMS Application.
not contain other files. Ensure that the directory allows any user to read and
execute the files and has enough space for extracting Insight upgrade files.

# mkdir -p
/opt/emsInstall/<NEW_EMS_VERSION>/
Example: To upgrade to 9.3, execute following command to create a

directory:
3. Download the ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso and upgradeEMS.sh files from the

Sonus Salesforce Customer Portal to /opt/emsInstall/<NEW_EMS_VERSION> / directory.
5. Change the execute permission of upgradeEMS.sh using the following command:
Before upgrading using Sonus Salesforce Customer Portal, you need to take a backup of /etc/ntp.conf and /
etc/issue files. You can restore this after completing the upgrade.
Sample Standalone Configuration File
While performing a Standalone upgrade, a configuration file ems_upgrade.conf is generated, which has
parameters related to backup. The ems_upgrade.conf configuration file also displays the comments marked for
each of the parameters inside the ems_upgrade.conf configuration file. A sample configuration file with
parameter details is given for here for reference.


#


are not read,
if "_ems_backup" is set to "false".
_ems_backup=
# Directory, where the EMS backup should be kept. Please modify, if required.


# By default, the value is set to "true" for KICKSTART-upgrade

and "false" for INPLACE-upgrade.
# Change the value to "false", if the backup of System Configuration
files like IP configs/crontabs/host files etc. are not required.
remote server.
# By default, the value is set to "true" for KICKSTART-upgrade and
"false" for INPLACE-upgrade.Change it to true/false to override the
default value.
# Remote Server Details : The following are to be given only if this

server has a password-less connection to the remote server where you want
the backup to be copied. This configuration will be read, only if
_backup_remote_IP=


Download the PSX Manager GUI TAR file SSGUI_V09.03.00R000_RHEL.tar from the Sonus Salesforce
Firmware Upgrade
ISO Upgrade
ISO Upgrade
You can perform an ISO upgrade using either INPLACE or KICKSTART upgrade type. Be default, the
operating system. In case, you want to perform a KICKSTART upgrade then you need to change the value of
upgradetype parameter to KICKSTART in ems_upgrade.conf configuration file.
Also, for upgrading from EMS 09.03.00R000 to a post-09.03.00 EMS minor or patch release, use the EMS
ISO upgrade method. For example, for upgrading from EMS V09.03.00 to EMS V09.03.01, use the ISO
upgrade method.
To summarize, in KICKSTART upgrade the high-level steps you need to perform are:
1. Take a back up of the existing EMS configuration to a remote machine.

2. Kickstart the system with the EMS Software Release V09.03.00 ISO. This performs an installation of
Operating System, database, and EMS Software Application.
3. Restore and download the backup from remote machine to the system.
It is recommended to use INPLACE upgrade. Before upgrading using Sonus Salesforce Customer Portal,
you need to take a backup of /etc/ntp.conf and /etc/issue files. You can restore this after completing the
upgrade.
The Insight Standalone upgrade is done using the upgradeEMS.sh and

ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso ISO file that you obtained from the Sonus
Salesforce Customer Portal. As per your requirement, upgrade EMS Software upgrade, using any of the following
mentioned ISO upgrade procedures:
INPLACE Upgrade
KICKSTART Upgrade
INPLACE Upgrade
INPLACE Upgrade Procedure

ID/trace
Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700
The total time taken for upgrading and total service downtime of the EMS Standalone server during the ISO
INPLACE upgrade is 35 to 40 minutes approximately.
You can perform an ISO upgrade using either INPLACE or KICKSTART upgrade type. By default, the
operating system.
Before performing the upgrade, you need to take a backup of /etc/ntp.conf and /etc/issue files.
You can restore these files after the EMS upgrade is complete.
To upgrade the EMS Standalone system using INPLACE upgrade, perform the following steps:

2. Verify if the ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso and upgradeEMS.sh files
are downloaded and available at /opt/emsInstall/<NEW_EMS_VERSION>/
3. Change directory to /opt/emsInstall/<NEW_EMS_VERSION>/.
directory to /opt/emsInstall/9.3.x/ (replace <NEW_EMS_VERSION>) with 9.3 in the following
command:

# ./upgradeEMS.sh -p
Skip step 7, and continue with step 8.

file]


#


_ems_backup=

required.



remote server.
_backup_remote_IP=



c. After you have generated and updated the ems_upgrade.conf file, execute the following command:
# ./upgradeEMS.sh -c [Absolute Path of ems_upgrade.conf configuration

file] -p
8. The system gets rebooted if there is an OS upgrade involved. The upgrade will continue after the system
starts.
After the system is up, execute the following command to see the upgrade progress:
# tail -f /var/sadm/install/logs/upgradeEMS.log
# rpm -qa SONSems

SONSems-V09.03.00-R000.x86_64
06.04.02.00R000
# uname -r
2.6.32-504.3.3.el6.x86_64
$ sqlplus -version

version:
(19271438)"
KICKSTART Upgrade
KICKSTART Upgrade Procedure
To upgrade the EMS Standalone using a KICKSTART upgrade, perform the following steps:
1. Log in as a root user to the Insight EMS server.

2. Verify that ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso and upgradeEMS.sh have
been downloaded to /opt/emsInstall/<NEW_EMS_VERSION>/
3. Change the directory to the path /opt/emsInstall/<NEW_EMS_VERSION>/ where the

ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso and upgradeEMS.sh files have been
copied.
command:
5. Generate the ems_upgrade.conf configuration file and change the _upgrade_type to KICKSTART, by

5.
executing the following command.
a. Execute the following command to generate the configuration file.

file]
For example, if you want to generate the ems_upgrade.conf file at the path
/opt/emsInstall/<NEW_EMS_VERSION>/ then execute the following command. Executing the
following command, generates the ems_upgrade.conf file at the specified path.
b. After the configuration file is generated, change the value of parameter _upgrade_type to
KICKSTART inside the ems_upgrade.conf configuration file The ems_upgrade.conf configuration
file also displays the comments marked for each of the parameters inside the ems_upgrade.conf
configuration file.
Save the ems_upgrade.conf configuration file, after performing the necessary changes.
6. Execute the following command to take backup of configuration to a remote machine:
Please make sure that in the BIOS boot order harddisk has given the highest preference so that if

7. Enter the remote machine details when the script prompts you to specify the location where the backup of
configuration files has to be stored.
about kickstarting system, refer Installing EMS ISO Image.
9. After the system is kickstarted, verify that EMS has been upgraded to version V09.03.00, by executing the
following command:
# rpm -qa SONSems

SONSems-V09.03.00-R000.x86_64
10. Change the directory to /opt/sonus/ems/conf by executing following command:

11. Restore the backup from remote machine to the system, by executing the command ./upgradeEMS.sh -r:
Enter the remote machine details when the script prompts for it to download the backup files from the remote
machine.
06.04.02.00R000
# uname -r
2.6.32-504.3.3.el6.x86_64
$ sqlplus -version

version:
(19271438)"

SA Post-Upgrade Tasks
After completing the EMS upgrade, ensure that the PSX manager GUI, iLO firmware version, and Device Manager
are upgraded to the latest. For more information, refer Performing Post-Upgrade Tasks.
Overview
The EMS HA Upgrade feature enables you to upgrade from EMS Software Release 9.1.x to 9.3.x.
Also, for upgrading from EMS 09.03.00R000 to a post-09.03.00 EMS minor or patch release, use the EMS
ISO upgrade method. For example, for upgrading from EMS V09.03.00 to EMS V09.03.01, use the ISO
upgrade method.
Table 38: Examples Depicting Selection of Upgrade Method
V09.01.00 V09.03.00 ISO Upgrade
V09.03.00 V09.03.01 ISO Upgrade
To perform an upgrade, you need to execute the script upgradeEMS.sh on the Primary Server and point to the
path of the ISO.
The configuration file has a parameter upgradetype. The parameter upgradetype designates the type of
upgrade - INPLACE or KICKSTART. The EMS HA Upgrade only supports INPLACE upgrade,
Prerequisites
The following are prerequisites for upgrading Insight EMS HA deployment or EMS DR site with HA servers from
software release 9.1.x to 9.3.x are as follows:
Both the primary and the secondary servers must be Up and Running.
You can check the current status of both the primary and secondary servers, using the /opt/sonus
/ems/conf/HA/RAC/sonusEMS status command.
Both the primary and secondary servers are installed with Insight EMS software release 9.1.x.
The primary and non-primary servers meet the minimum hardware requirements.
Ensure that Active EMS must be running on the Primary EMS server, prior to the EMS upgrade procedure.

Primary node can be determined by executing the following command:
Similarly, Secondary node can be determined by executing the following command:
In case primary is not Active, switchover needs to be done using sonusEMS relocate command.
Do not execute the EMS upgrade procedure on a SSH window where it is connected through the Cluster
virtual or logical IP address.
Login through the physical IP address on EMS interface eth0.
The EMS upgrade procedure must be executed as superuser "root".
links in the WL9.3 software bundle and download the files mentioned in Downloading Upgrade Files section.
The files required to upgrade HA servers or HA servers deployed at a DR site are:

The ISO file Perform the following steps to download emsrac-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso and upgr
emsrac-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso adeEMS.sh files:
updates. The ISO file must be stored in the same path
where upgradeEMS.sh script is downloaded.
are upgrading. For example, to upgrade to 9.3 release, instead of <NEW_EMS_VERSION> s
pecify 9.3 as directory name. The directory <NEW_EMS_VERSION> where you are
perform ISO upgrade. The upgradeEMS.sh file performs all
downloading the file, must be empty and must not contain other files. Ensure that the
the necessary tasks such as system checks, create backup
directory allows any user to read and execute the files and has enough space for
of configuration, upgrade OS, Database and EMS
extracting Insight upgrade files.
Application.

Example: To upgrade to 9.3, execute following command to create a directory:
3. Download the emsrac-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso and upgradeEMS.sh file available under W

L9.3 Software Bundle from the Sonus Salesforce Customer Portal to /opt/emsInstall/<NEW_EMS_VERSION>/
directory.
The downloaded file emsrac-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso must

be stored in the path which is reachable while executing the upgradeEMS.sh script.
5. Change the execute permission of upgradeEMS.sh file by executing the following command:
Firmware File (Optional)

Downloading the HP firmware file is optional, and needed only if the HP firmware version is not the latest.
For more information about HP firmware latest version and procedure to upgrade the HP firmware, refer the
page https://support.sonus.net/display/ALLDOC/HP+DL380p+G8+Firmware+Upgrade.
This is the HP G8 DL380 firmware upgrade file. Ensure that the HP DL380 G8 firmware is upgraded after Download the firmware file from Salesforce Customer Portal to: /opt/sonus/p
you perform the EMS Software upgrade. latform directory in the server.
Sample HA Configuration File
While performing an HA upgrade, a configuration file ems_upgrade.conf is generated, which has parameters
related to backup. The ems_upgrade.conf configuration file also displays the comments marked for each of the
parameters inside the ems_upgrade.conf configuration file. A sample configuration file with parameter details is
given for here for reference.


#
_ems_backup=true
ISO Upgrade for HA

ISO Upgrade for HA

Total time for upgrading both the primary and secondary servers using ISO upgrade is approximately 40 to
45 minutes.
The following steps are executed only on the EMS Primary Server that is Active. To upgrade the EMS HA using an
ISO file, perform the following steps:
Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700
1. Log in as a root user to the Insight EMS Primary server that is Active.
2. Change the directory to the path where the
emsrac-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso and upgradeEMS.sh files have been
copied.

# ./upgradeEMS.sh -p [Absolute Path of the ISO file]
a. After reboot, when the primary server is up, login as root user and verify that EMS has been
upgraded to version 9.3.x, by executing the following command:
# rpm -qa SONSems

SONSems-V09.03.00-R000.x86_64
b. On the secondary server, verify that the EMS software has been upgraded to 9.3.x, by executing the
following command:
# rpm -qa SONSems

SONSems-V09.03.00-R000.x86_64
After the upgrade is performed successfully on both the primary and secondary servers, the
original active server would be standby and the original standby server would be active. To
revert to the original state, execute the command /opt/sonus/ems/conf/HA/RAC/sonu
sEMS relocate.
The above procedure completes the default upgrade process for both the active and standby servers
for a EMS HA deployment.

a.

file]


#
_ems_backup=true

7. After you have generated and updated the ems_upgrade.conf file, execute the following command:

[Absolute path of the EMS HA ISO File]
information, see Rollback EMS HA.
8. After reboot, when the primary server is up, login as root user and verify that EMS has been upgraded to
version 9.3.x, by executing the following command:
# rpm -qa SONSems

SONSems-V09.03.00-R000.x86_64
9. On the secondary server, verify that the EMS software has been upgraded to 9.3.x, by executing the following
command:

9.
# rpm -qa SONSems

SONSems-V09.03.00-R000.x86_64
10. Perform the following steps to verify if database and kernel have been updated:
06.04.02.00R000
# uname -r
2.6.32-504.3.3.el6.x86_64
$ sqlplus -version

version:
(19271438)"
After the upgrade is performed successfully on both the primary and secondary servers, the original
active server would be standby and the original standby server would be active. To revert to the
original state, execute the command /opt/sonus/ems/conf/HA/RAC/sonusEMS relocate.
The above procedure completes the upgrade process using the upgrade configuration file for both the active

and standby servers for a EMS HA deployment.

In case, the database size is not sufficient, you can increase the DB size using the ASM Partition mechanism.
Increasing the ASM partition size is an optional procedure and increasing the DB size is dependent on insufficient
DB space.
Increasing ASM Partition Size is optional and is applicable only for IBM DS3524 RAID.
Caution
If you have sufficient DB space available, there is no need to execute the ./ASMPartition script.
If you do not have sufficient DB space, you can increase the DB size, by executing the following
1. Log in as root user to the Active Server.

2. Change the directory to /export/home/pkg
3. Assign the privilege to execute the ./ASMPartition script on both the active and standby server, using the
following command:
# chmod +x ASMPartition
4. Execute the ./ASMPartition command on the active server to increase the DB size. Execute the
command ./ASMPartition from the active server.
# ./ASMPartition
Executing the ./ASMPartition script, takes substantial time to complete. Please wait for the
script to complete execution. Executing the ./ASMPartition command automatically reboots both
the servers.
After the ./ASMPartition script completes the execution, the original active server would be
standby and the original standby server would be active. To revert to the original state, execute the
command /opt/sonus/ems/conf/HA/RAC/sonusEMS relocate

After completing the EMS HA upgrade, ensure that the NTP server, PSX manager GUI, iLO firmware version,
Device Manager, and IBM V3700 RAID Firmware version are upgraded to the latest. For more information, refer
Post-Upgrade Steps.
EMS DR Upgrade
Overview
For upgrading a DR pair (source and target), first you need to upgrade the Source DR site and then upgrade the
Target DR site. The upgrade procedure is same as upgrading the Standalone and HA Upgrade.
Upgrading Standalone Systems for DR Setup
The following are the high-level steps of upgrading DR with standalone systems. First execute the upgradeEMS.sh
script on Source SA server. After upgrading the SA EMS server, execute the upgradeEMS.sh script on Target SA
server within 15 minutes.
configuration.
Backup the EMS by splitting the disk mirror on the source and target EMS standalone system.

source EMS system.
EMS system.

Re-Mirror the disks on the source and target EMS standalone system.
Upgrading High Availability (HA) Systems for DR Setup
The following are the high-level steps of upgrading DR with HA systems. First execute the upgradeEMS.sh script
on Primary server that is Active at the Source DR Site. Based on whether you are upgrading to EMS Software
Release V09.03.00 (ISO Method) or upgrading to a sustaining release post-V09.03.00, select the appropriate
upgrade method.
Execute the upgradeEMS.sh script on Primary server that is Active at the Source DR site. After upgrading the
source DR Site, execute the upgradeEMS.sh script on Primary server that is Active at the Target DR Site.
After downloading the file upgradeEMS.sh, login as ‘root’ user and change the permission of upgradeEM
S.sh using the following command:
b. After completing the DR Source site upgrade, perform INPLACE ISO upgrade procedure
on the DR target primary EMS system.

In case, the database size is not sufficient, you can increase the DB size using the ASM Partition
mechanism. Increasing the ASM partition size is an optional procedure and increasing the DB size is
dependent on insufficient DB space. For a DR setup, if there is insufficient DB space, the ./ASMPartitio
n script needs to be executed on both the DR source and DR target sites. For more details, refer the section
Increasing ASM Partition size .

Insight EMS SWe Installation and Upgrade
This section provides information on installing and upgrading Insight EMS SWe on virtualized environment.
Table of Contents

Virtualization is a key feature and is evolving to become a major factor in the software industry. The benefit of
software virtualization is that it can be installed on any hardware over a virtual machine. In a step closer towards
virtualization and removing dependencies on hardware, Sonus has made significant progress by virtualization of the
Insight EMS. The Insight EMS Virtualization on Kernel Virtual Machine (KVM) is available from release 9.2.0 and
later releases. The Insight EMS Software Edition can be installed on KVM version 0.10.2 or above from release
9.2.0 onwards.
Sonus has further extended virtualization support in release 9.3.0, by providing deployment of EMS Software Edition
(SWe) virtually on VMware ESXi server. The EMS SWe can be installed virtually on VMware ESXi for Standalone
(SA), High Availability (HA), and Disaster Recovery (DR) deployments for small and large configurations.
The complete EMS Software Edition solution consists of the following components:
Customer Provided:
Hardware—System (compatible to run EMS Software Edition), memory, CPU, network cards, and disk drives.
KVM Hypervisor—KVM (Kernel Virtual Machine version 0.10.2) hypervisor running on RHEL 6.4 host
operating system. The hypervisor gives each VM a dedicated view of the hardware.
VMware ESXi operating system hosted on Hypervisor—VMware ESXi 5.1 or above running on hypervisor.
The hypervisor gives each VM a dedicated view of the hardware. EMS SWe software 9.3.0 runs virtually on
virtual machine created on VMware server.
VMware Client installed on your system—VMware Client 5.1 or above installed on your system through which
you access the VMware ESXi server.
If you are deploying EMS HA on KVM or VMware ESX, ensure that you have two physically
separate systems (primary and secondary) on which you are installing EMS. To avoid single point of
failure, you must have two physically separate systems; on each system you install RHEL 6.4 OS
with KVM or VMware ESX.

Sonus EMS Software:
The EMS Software Edition appears to users as an independent Sonus EMS with its own network identity, user
authorization and authentication capabilities, as well as configuration and data.
The EMS Software Edition application can be deployed in the following environment:
On a dedicated server: The EMS application exists on a Commercial Off-the-Shelf (COTS) hardware rather
than a proprietary platform.
Configurations Supported for EMS Software Edition

This section describes the different configuration types for which the Virtual Machine (VM) for Standalone (SA) and
High-Availability (HA) deployment can be done. The EMS Software Edition supports following deployment
configurations on Virtual Machines for Standalone (SA) and High-Availability (HA) deployments.
Small Configuration
Large Configuration
In these sections, 1 GB refers to 1 x 1024 x 1024 x 1024 = 1073741824 bytes. For example, a 300 GB size
is 3221225472 bytes.
Small Configuration
Depending on the requirements, you can either deploy EMS Software Edition in SA or HA on a VM for a 'small' or
'large' configuration. If you want to manage less network devices, you can opt for 'small' configuration.
Large Configuration
If the number of devices to be managed are more and you want better performance, you can opt for 'large'
configuration.
The hardware requirements for 'small' and 'large' configuration are different. For more details, regarding EMS
Standalone and High Availability hardware requirements, refer the following links:
KVM Installation Requirements

VMware ESXi Installation Requirements

The Insight EMS Virtualization on Kernel Virtual Machine (KVM) is available from release 9.2.0 and later releases.
The Insight EMS Software Edition can be installed on KVM version 0.10.2 or above from release 9.2.0 onwards.

If you want to install EMS SWe virtually on Kernel Virtual Machine (KVM) for Standalone (SA) or
High-Availability (HA) deployments, refer the following pages.
Introducing Insight EMS SWe on KVM

Hardware and Software Requirements for Insight EMS SWe on KVM
Installing Insight EMS SWe on KVM
Upgrading Insight EMS SWe on KVM
Common Administrative Tasks
Introducing Insight EMS SWe on KVM
Overview
Insight EMS Software Edition(SWe) is a virtual Sonus EMS appliance that is hosted on any compatible hardware
that supports virtualization. The benefit of software virtualization is that it can be installed on any hardware over a
virtual machine. In a step closer towards virtualization and removing dependencies on hardware, Sonus has made
significant progress by virtualization of the Insight EMS on KVM.
The complete EMS Software Edition solution consists of the following components:
Customer Provided:
Hardware—System (compatible to run EMS Software Edition), memory, CPU, network cards, and disk drives.
KVM Hypervisor—KVM (Kernel Virtual Machine version 0.10.2) hypervisor running on RHEL 6.4 host
operating system. The hypervisor gives each VM a dedicated view of the hardware.
VMware ESXi operating system hosted on Hypervisor—VMware ESXi 5.1 or above running on hypervisor.
The hypervisor gives each VM a dedicated view of the hardware. EMS SWe software 9.3.0 runs virtually on
virtual machine created on VMware server.
VMware Client installed on your system—VMware Client 5.1 or above installed on your system through which
you access the VMware ESXi server.
If you are deploying EMS HA on KVM or VMware ESX, ensure that you have 2 physically separate
systems (primary and secondary) on which you are installing EMS. To avoid single point of failure,
you must have two physically separate systems; on each system you install RHEL 6.4 OS with KVM
or VMware ESX.
Sonus EMS Software:
The EMS Software Edition appears to users as an independent Sonus EMS with its own network identity, user
authorization and authentication capabilities, as well as configuration and data.
The EMS Software Edition application is deployable in the following environment:
On a dedicated server: The EMS application exists on a Commercial Off-the-Shelf (COTS) hardware rather
than a proprietary platform.
EMS SWe Standalone Configuration
A single EMS VM is used for managing the network elements. The following figure shows the block diagram of
components involved in running EMS SA in a KVM based environment.

Figure 96: EMS SA for KVM Block Diagram
EMS SWe High Availability (HA) Configuration
The following figure shows the block diagram of components involved in running EMS HA in a KVM based
environment.

Figure 97: EMS HA for KVM Block Diagram
Hardware and Software Requirements for Insight EMS SWe on KVM
To install and configure the EMS software edition, ensure that the Virtual Machine (VM) host meets the
recommended hardware, server platform, and software requirements.
The hardware and software settings are intended to ensure optimum EMS SWe stability and performance
for small and large configuration. If these settings are not used, EMS SWe system may not perform as
expected.
Depending on the SA or HA Deployment type of installation, refer the following installation requirement
section:
Virtual Resource Requirements


This section provides information for small and large standalone and HA deployment configurations:
Minimum CPU rating that is supported is 2.0 GHz. Sonus will not support users with CPUs below 2.0 GHz.
Standalone Configuration
Table 40: Standalone Hardware Requirements
Configuration Type vCPU vMemory (GB) vHDD (GB) vNIC
Small 4 8 300 1
Large 12 32 900 1
High Availability (HA) Configuration
Table 41: High-Availability Hardware Requirements
Configuration vCPU vMemory vHDD (GB) SAN Disk vNIC

Type (GB)
Small 4 8 250 GB (VM 1), 250 GB 90 GB (ASM), 60 GB 2 (1 Public + 1

(VM 2) (EMS) Private)
Large 12 32 250 GB (VM 1), 250 GB 600 GB (ASM), 300 GB 2 (1 Public + 1

(VM 2) (EMS) Private)
Here, the vCPU is independent of the underlying hyperthreaded core hardware.
Installation Requirements for Standalone (SA) Deployment on KVM
This section provides details about the software and hardware requirements for performing SA installation on KVM:
Hardware that the host system is running, must have at least enough system and network resources (CPU,
disk, memory, and network) as the VMs that are planned to be created on the host.
Disk Space Requirements
To use the EMS Software Edition in a virtualized environment, Storage Area Network (SAN) must be used to store
the configuration data, the Operating System (OS) and EMS packages, EMS files, Oracle Automatic Storage
Management (ASM) files. The disk space and partitioning requirements, are different for 'small' and 'large'
configuration.
The EMS Software Edition installed on a virtualized environment, supports both local storage or remote
SAN storage (iSCSI LUN) to store the data. If a direct-attached RAID is to be used, ensure that the RAID
disks (LUNs) of required size are exposed on the host.
SAN Setup Requirements
The high-level SAN setup requirements to use Storage Logical Unit Numbers (LUNs) in a virtualized environment
are:

SAN administrator must be knowledgeable about SAN concepts, managing and creating LUNs, and
setting-up the connectivity.
The Storage LUNs of the right size must be available on the host and exposed to the VMs being created as
SCSI disks.
The LUNs that are meant to be shared in case of an HA setup; ensure that both the HA nodes are pointing to
the same LUN on the SAN.
Shared disks must be displayed as SCSI disks within the VM.
Installation Requirements for High-Availability (HA) Deployment on KVM
This section provides hardware and software requirement details for installing EMS SWe for HA deployment on
KVM.
Management (ASM) files. The disk space and partitioning requirements are different for 'small' and 'large'
configuration.
The EMS Software Edition installed on a virtualized environment supports both local storage or remote SAN
storage (iSCSI LUN) to store the data.
Network Requirements
Network connections (public and private) between the two VM hosts need to be established just as in the case of a
physical (HP G8) based HA setup. Configure the private and public network connections between hosts as shown in
Cabling and Network Connectivity for Insight EMS High Availability Cluster . Instead of direct-attached RAID, SAN
network connections need to be established between the two VM hosts to the SAN switch.
EMS HA Solution
Relevant network connections (separate from public/private HA network) and bonding must be setup for the storage
network to enable SAN storage.
are:
SCSI disks.
In case of an HA setup, where the LUNs are meant to be shared, ensure that both the HA nodes are pointing
to the same LUN on the SAN.
For an HA setup, execute the scsi_id command on both nodes and ensure that it displays the same value
for shared disk on both nodes.

The disk space requirements for High Availability (HA) 'small' and 'large' configuration on a virtual environment
(KVM) are specified in the High-Availability Hardware Requirements.
For better understanding the usage of each disks for EMS HA (small or large configuration), refer the following table:
Table 42: Disks and Usage for EMS HA Setup
Disk Disk Size for Disk Size for Usage

HA Large HA Small
Configuration Configuration
Disk 250 GB (VM 1), 250 GB (VM 1), Used to store the OS and EMS packages. This disk can be either a local or
1 250 GB (VM 2) 250 GB (VM 2) a remote disk (iSCSI LUN).
Disk 300 GB (EMS) 60 GB (EMS) It is a shared disk used to store EMS files. The remote disk can be used
2 using iSCSI or direct attached (example IBM DS3524/IBM V3700) FC
connections.
Disk 600 GB (ASM) 90 GB (ASM) It is a shared disk used to store Oracle ASM files. The remote disk can be
3 used using iSCSI or direct attached (example IBM DS3524/IBM V3700) FC
connections.
This section provides host hypervisor software requirements for EMS SA and HA deployments.
The following is the KVM software requirement:
KVM Requirements
Ensure that only the following or later versions of RHEL and KVM module are used. Earlier versions are not
supported.
Software Version For more information
Red Hat Enterprise Linux 6.4 or above Install RHEL 6.4 OS in 'Virtualization Host' mode.
KVM Module 0.10.2
To check the version of KVM installed, execute the following command:
# libvirtd --version
libvirtd (libvirt) 0.10.2
Also, when installing the RHEL 6.4 OS, you need to configure one network interface (example, eth0) for public
network connection. To enable the VM running on the host to share this public network interface, you need to create
a network bridge (example br0). This bridge allows the VM's virtual network interface (example eth0) access to the
public network, using the vnet0 network interface.

If you are using a later version of the Red Hat Enterprise Linux (RHEL) or Kernel Virtual Machine (KVM)
module, the screen shots provided may not match exactly and vendor documentation should be followed in
this case.
EMS SWe Requirements
Table 43: Software Requirements
Configuration Version
EMS SWe V09.03.0R000
Installing Insight EMS SWe on KVM
This section provides information on installing Insight EMS SWe on KVM.
Installing EMS SWe Standalone or IAS SWe on KVM

EMS SWe HA Installation Procedure for KVM
EMS SWe DR Configuration for KVM
Installing EMS SWe Standalone or IAS SWe on KVM

This page provides Standalone EMS SWe or IAS SWe installation procedure for Linux on KVM. If you are installing
EMS or IAS Software virtually for a standalone deployment on KVM, refer the following sections.
Installing EMS SA or IAS SWe Software on KVM
Before proceeding, ensure that the hardware and software requirements to install EMS SA or IAS are met.
The following summary outlines the key steps required to install EMS Standalone or IAS software-only application
on KVM.
Preparing the host
This step lists the prerequisites for Host OS installation, recommendation for using local or remote storage
and installation checklist.
Downloading ISO from SalesForce
This step shows you what and how to download the EMS Standalone or IAS ISO package from SalesForce.
Creating EMS or IAS Virtual Machine Instance and Performing ISO Installation
This step creates the Virtual Machine (VM) instance for installing EMS SA or IAS on KVM and performs ISO
installation.

Performing Post-Installation Tasks
This step shows you how to perform the mandatory post-installation tasks.
If you are doing an IAS installation, this step is not applicable. Post-installation tasks are only
performed for EMS installation.
Preparing the host
This section provides installation prerequisites, recommendations for storage and installation checklist.
Prerequisites for Installation
The following are the prerequisites that are required prior to installation:
Read the latest Sonus Insight release notes for important information.
Download the latest version of EMS Software Suite 9.3.0 documents from the Sonus Salesforce Customer
Portal.
Must be aware of basic understanding of initial BIOS sequence or procedure.
Warning Notices (WBAs)—Sonus recommends that you view the warning notices pertaining to this release to
see if your software or hardware platforms are affected. If you have an account on Sonus Salesforce
Customer Portal, you can find the warning notices at
https://c.na8.visual.force.com/apex/SolutionList?sfdc.tabName=01r80000000Q04H. If you do not have a
Sonus Salesforce Customer Portal login account, you can contact the Sonus Technical Assistance Center
(TAC).
Preparing Host System for VM Installation
This section gives an overview of what needs to be done to prepare the host system before creating a Virtual
Machine (VM).
1. If you are planning to use SAN-based storage for shared disks, instead of direct-attached RAID storage, then
perform the following tasks:
a. Create LUN volumes on the SAN as per disk size requirements. For more information about disk
space requirements, see the section Disk Space Requirements.
b. Login to the SAN through iSCSI and make sure the disks are visible on the host.
c. The Storage Administrator must setup the SAN hardware and associated connections to the host,
using iSCSI for example.
i. Storage connections between host and the SAN box should be fast—1G at least (10G better).
ii. Set up adequate level of redundancy—network bonding of storage interfaces, and/or IO
multipathing.
iii. Isolate the storage network traffic—do NOT use the storage network for any non-storage related
traffic.
2. Ensure you have console access to the host systems for RHEL OS installation.
Using Local or Remote Storage
The primary storage disk for VM can be either local or remote (iSCSI SAN). If you are using local storage, a raw disk
of appropriate size functions as the VM disk.
Recommendations when using Remote SAN Storage

The recommended actions to be performed, when using a remote SAN connection are:
To avoid a single point-of-failure, sufficient redundancy must be configured and available at various points of
storage path. Some of the examples of redundancy are, network bonding on the host (example using bond2),
redundant storage switch, IO multipathing on storage device, and so on.
If you are using LUN disks, it is recommended to set up IO multipathing on the host to create persistent
device paths that are available across host reboots.
After the LUN is exposed as disk on the host, it can either be used directly in the VM or it can be formatted
and partitioned and a disk image can be created there, which in turn is used as the VM disk.
Installation Checklist
Prior to installing EMS software, you need to collect the information listed below.
Parameter Description Examples of

Value for
your system
(fill in)
Primary The Primary Network Interface (PNI) of the system. eth0

network
interface
name
Host name The name which identifies the system on the network. ems1
The EMS hostname is limited in length to 64 characters. The hostname can

only contain lowercase letters [a-z] and digits [0-9]. The hostname cannot
start with a digit. Special characters including hyphen are not allowed in
hostname.
IP address The Internet Protocol (IP) address for the network interface. 10.9.9.103
Default The node on a TCP/IP network that serves as an access point to another network. 10.9.9.1
router
Netmask The mask used to determine to which subnet an IP address belongs. 255.255.255.0
of subnet
NTP The Network Time Protocol server to which the system containing VM synchronizes the time. 10.9.9.5
DNS The DNS servers of this network. 10.9.9.6
Timezone The timezone where the VM host system is located. Asia/Kolkata
This section provides information on how to download the EMS release 9.3.0
ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso package from the SalesForce Customer Portal.

Download both the files ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso to the host
system.
1. Login to Salesforce Customer Portal.

2. In Secure Customer Login, enter your Username and Password. The Sonus Global Support Portal displays.
3. From the Salesforce Customer Portal, click the SOFTWARE DOWNLOADS tab. The Software Downloads
screen displays.

6. Enter the address details and accept the license agreement.
8. Click the SOFTWARE REQUESTS tab. The Software Requests Home screen displays.
11. Download the EMS ISO file ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso package from
the Salesforce Customer Portal to the VM host system under /home/images directory.
a. Create a directory /home/images on the host system and copy the
ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso file at the path /home/images.
The iso file will later be used to install Insight EMS on VM guest.
i. Execute the following step to create a /home/images directory.
# mkdir /home/images
ii. Ensure that the ISO file is copied at the path /home/images on the host system.
Creating EMS or IAS Virtual Machine Instance and Performing ISO Installation
For host hypervisor software requirements, refer the section Software requirements.
Procedure to manually create a Virtual Machine Instance for Standalone Setup
Perform the following steps to manually create a Virtual Machine (VM) instance for a standalone setup:
1. Login to host console as root user, and launch KVM Virtual Machine Manager GUI by executing the
following command:
# virt-manager&
2. Click Create a new virtual machine. Specify an appropriate name for the VM as shown in the following
figure.

Figure 98: Create a new virtual machine
3. Choose the path of EMS .iso file, and select the OS type as Linux and version.
Figure 99: Select OS and version
4. Specify the CPU and Memory resources for the VM. Refer Hardware and Software Requirements for Insight
EMS SWe on KVM for CPU and memory specifications.

4.
Figure 100: Specify the CPU and Memory resource
5. Clear the Enable storage for this virtual machine check box. Storage is added later at the end of VM
creation. Refer Figure 4.

Figure 101: Disable storage for this virtual machine
6. Select the Customize configuration before install check box and click Finish. Refer Figure 5.
Figure 102: Customize configuration

The following screen is displayed.
Figure 103: emsvmsa Virtual Machine screen
7. Click Add Hardware (refer Figure 6) and add a local disk (300 GB or 900 GB based on small or large config)
with the settings shown in Figure 7 and click Finish.
Figure 104: Add New Virtual Hardware
8. Under Boot Options, select the Autostart check box and click Apply to save the changes. Refer Figure 8.

Figure 105: Check Autostart and save changes
9. Click Begin Installation to start the installation. Refer Figure 8.

10. Type 1 and press Enter. Refer Figure 9.
Figure 106: Begin Installation
11. Once installation is completed, you should see the reboot screen shown in Figure 10. ISO installation may
take about 10 minutes.

Figure 107: Installation complete screen
12. From the Shutdown the virtual machine option, choose Force Off.
13. Browse to Show virtual hardware details screen. Select IDE CDROM 1 option and click Disconnect to
un-mount the iso. Refer Figure 11.
Figure 108: Disconnect the iso
14. Go back to the Show the graphical console screen and click Power on the virtual machine to continue
with the rest of the installation.
15. Network configuration screen is displayed as shown in Figure 12.

15.
Figure 109: Network configuration
16. Select Hostname and press the Space key to configure the hostname for the system.
Figure 110: Network Configuration Screen
17. Specify a relevant Hostname using which you can easily identify the VM host.

17.
Figure 111: VM Hostname Configuration Screen
18. Enter the IP Address, Subnet Mask, and Gateway details for the virtual interface.

Figure 112: Virtual Interface IP Address Configuration Screen
19. Select the TimeZone where the VM host system is located from the list of time zones.

Figure 113: TimeZone Configuration Screen
20. Enter the NTP Time-Server IP Address, to synchronize the time for the VM host system.

Login screen is displayed, after the EMS Application Software Suite is successfully installed on the VM host.
21. Login as root user to the EMS Software on the VM host system.
Change the password of the root user the first time you login to the EMS application.

Figure 115: EMS Application Login Screen
This completes the EMS installation on the VM host system.

22. If you are installing EMS, ignore this step. If you are installing IAS, run remoteIasInstall.sh script on
EMS server and provide the IAS IP address. For more information, refer the section Installing Insight
Application Server on Virtualized Environment.
Troubleshooting Installation Tip
During EMS installation, ignore the following errors, unless DB Instance creation fails. The following
Error Codes:
ORA-00942
ORA-942
EMS SWe HA Installation Procedure for KVM

This page provides EMS HA Software only installation procedure for Linux on KVM. If you are installing EMS
Software virtually for a HA deployment on KVM, refer the following sections:

Installing EMS HA SWe Software on KVM

Preparing the host
VM Storage
Information Required Prior for Installing Insight HA
Creating EMS Virtual Machine Instance
Procedure to manually create a Virtual Machine Instance for HA Setup
Performing EMS HA ISO Installation
Installing EMS HA Application and Configuring HA
Setting values in Configuration File
Running EMS installation scripts
RACinstall_1 script
EMSRACinstall script
Installing EMS HA SWe Software on KVM
Before proceeding, ensure that the hardware and software requirements to install EMS HA are met.
The following summary outlines the key steps required to install EMS HA software-only application on KVM.
Preparing the host
This step lists the prerequisites for installation, recommendation for using SAN storage and installation checklist.
This step shows you what and how to download the EMS HA ISO package from SalesForce.
This step creates the Virtual Machine (VM) instance for installing EMS HA on KVM.
This step shows you how to perform an EMS HA ISO installation.
This step shows you how to install the EMS HA application and configure High-Availability for both the systems.
Preparing the host

This section provides installation prerequisites, recommendations for storage and installation checklist.
The following are the prerequisites that are required prior to installation:
EMS HA nodes on VM should be setup on two separate hardware nodes. This is done for redundancy.
Read the latest Sonus Insight release notes for important information.
Download the latest version of EMS Software Suite 9.3.0 documents from the Sonus Salesforce Customer
Portal.
Must be aware of basic understanding of initial BIOS sequence or procedure.
(TAC).
This section gives an overview of what needs to be done to prepare the host system before creating a Virtual
Machine (VM).
1. If you are planning to use SAN-based storage for shared disks then perform the steps below:
a. Create LUN volumes on the SAN as per EMS High Availability disk size requirements. For more
information, about disk space requirements see the section Disk Space Requirements.
b. Login to the SAN through iSCSI and make sure the disks are visible on the host.
c. The Storage Administrator must setup the SAN hardware and associated connections to the host,
using iSCSI for example.
i. Storage connections between host and the SAN box should be fast—1G at least (10G better).
ii. Set up adequate level of redundancy—network bonding of storage interfaces, and/or IO
multipathing.
d.
i. Isolate the storage network traffic—do NOT use the storage network for any non-storage related
traffic.
2. Ensure you have console access to the host systems for RHEL OS installation.
VM Storage
The primary storage disk for VM can be either local or remote (iSCSI SAN). If you are using local storage, a raw disk
of appropriate size functions as the VM disk. Storage for the two shared disks used by EMS HA have to be shared
on a remote storage device (iSCSI based SAN). EMS HA needs direct LUN access to the shared storage volumes
for HA functionality to work.
The recommended actions to be performed, when using a remote SAN connection are:
To avoid a single point-of-failure, sufficient redundancy must be configured and available at various points of
storage path. Some of the examples of redundancy are, network bonding on the host (example using bond2),
redundant storage switch, IO multipathing on storage device, and so on.
If you are using LUN disks, it is recommended to set up IO multipathing on the host to create persistent
device paths that are available across host reboots.
After the LUN is exposed as disk on the host, it can either be used directly in the VM or it can be formatted
and partitioned and a disk image can be created there, which in turn is used as the VM disk.

Prior to installing Insight HA system, collect and record the values for the system parameters shown in the table,
System Information required for Insight HA Installation.
All public IP addresses except DNS IP and iLO IP should be configured in same subnet.
The configuration information given below is tested in the lab condition and do not accurately portray a
properly configured system.
Parameter Value for your system (fill in) Examples
Cluster Configuration
Cluster The name of the cluster. emsha1

Name
The cluster name must be at least one character long and no

more than 15 characters in length, must be alphanumeric, and
may contain hyphens.
The name of the cluster can only contain lowercase letters [a-z], digits [0-9], and
hyphen [-].
The cluster name cannot start with a digit or hyphen, and cannot end with a
hyphen.
Cluster A virtual IP address used to uniquely connect to the EMS (owned by whichever 10.54.159.2
VIP server is active).
IPv6 A virtual IPv6 address used to uniquely connect to the EMS (owned by whichever fd00:10:6b50:4020::56/62
Cluster server is active).
VIP
(optional)
Gateway The IP address of the gateway. 10.54.159.1
of subnet
DNS The DNS servers of the network. 10.54.163.1

Servers
10.54.163.2
NTP The Network Time Protocol server. 10.128.254.68

Server

SCAN The first IP address used by the Oracle SCAN (single client access name) 10.54.159.200
Listener IP listener.
Address 1
SCAN The second IP address used by the Oracle SCAN (single client access name) 10.54.159.201
Address 2
SCAN The third IP address used by the Oracle SCAN (single client access name) 10.54.159.202
Address 3
Hostname The name which identifies the system on the network. wfdems01a
The EMS hostname is limited in length to 64 characters. The

hostname can only contain lowercase letters [a-z] and digits
[0-9]. The hostname cannot start with a digit. Special characters
including hyphen are not allowed in hostname.
Public IP The IP address on the public network for the node. 10.54.159.100
Address
Public The IPv6 address on the public network for the node. fd00:10:6b50:4020::56/61
IPv6
Address
(Optional)
Oracle VIP Virtual IP address that is assigned to Oracle Clusterware or RAC. 10.54.159.101
iLO IP The IP address that is used to connect to the iLO. 10.54.163.52

Address
Private IP An IP address assigned to a device on a private TCP/IP Local Area Network that 192.168.128.1 is the
Address is accessible only within the Local Area Network. default value, change if
required.
Hostname The name which identifies the system on the network. wfdems01b

Address

IPv6
Address
(Optional)

Address
required.
This section provides information on how to download the EMS release 9.3.0
emsrac-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso from the SalesForce Customer Portal.
1. Login to Salesforce Customer Portal.

2. In Secure Customer Login, enter your Username and Password. The Sonus Global Support Portal displays.
3. From the Salesforce Customer Portal, click the SOFTWARE DOWNLOADS tab. The Software Downloads
screen displays.

6. Enter the address details and accept the license agreement.
8. Click the SOFTWARE REQUESTS tab. The Software Requests Home screen displays.
11. Create a directory /home/images on the primary system and copy the
emsrac-V09.03.00R000-RHEL-06.04.02.00R000-x86_64.iso file at the path /home/images. The
iso file will later be used to install Insight EMS on VM guest.
a. Perform the following step on primary and secondary host to create a /home/images directory.
# mkdir /home/images
b. Ensure that the ISO file is copied at the path /home/images on the primary host.
For host hypervisor software requirements, refer the section Software requirements.

Procedure to manually create a Virtual Machine Instance for HA Setup
Pre-requisites:
1. Setup shared disks as per hardware requirements.

2. Create KVM iSCSI based storage pools for each shared SAN volume/disk, on both hosts.
3. Download the emsrac-*.iso from Salesforce portal and put the iso file in a location of your choice, on both
the primary and secondary hosts.
Procedure
Create the VM on the primary host first, followed by VM on the secondary host. Perform the following steps to
manually create the VM on the primary and secondary host:
The screenshots shown here are for VM being created on the primary host. After VM is successfully created
on primary host, these steps must be performed on the secondary host. Choose a different VM name (for
example: 'emsvmsec') for secondary VM host.
following command:
# virt-manager&
2. Click Create a new virtual machine. Specify an appropriate name for the VM. Refer Figure 1.
Figure 116: Create a new virtual machine
3.

3. Choose the path of emsrac .iso file, and select the OS name and version as displayed in following figure.
Figure 117: Select OS and version
4. Specify the CPU and Memory resources for the VM. Refer Hardware and Software Requirements for Insight
EMS SWe on KVM for CPU and memory specifications.

Figure 118: Specify the CPU and Memory resource
5. Clear Enable storage for this virtual machine checkbox. Storage will instead be added later at the end of
VM creation. Refer Figure 4.

Figure 119: Disable storage for this virtual machine
6. Select the Customize configuration before install check box and click Finish.
Figure 120: Customize configuration

You should see the screen displayed in the following figure.
Figure 121: Virtual Machine screen
7. Click Add Hardware (refer Figure 6) and add 250 GB local disk with the settings shown in the following
screen and click Finish.
Figure 122: Add New Virtual Hardware
8. Click Add Hardware and add the shared disk for ASM by selecting the previously configured storage pool
volume. See Pre-requisites. Configure the rest of the settings as shown in Figure 8 and click Finish.

Figure 123: Shared disk for ASM
9. Click Add Hardware and add the shared EMS disk volume. Configure the rest of the settings as shown in
Figure 9 and click Finish.
Figure 124: EMS disk volume
10. Click Add Hardware and add the private network by choosing Network and the previously configured device
bond1 (br1) as shown in Figure 10. Click Finish.

Figure 125: Add private network
11. Under Boot Options, select the Autostart check box and click Apply to save changes.
Figure 126: Check Autostart and save changes
12. Select ASM shared disk SCSI Disk 2 and select the Shareable check box. Click Apply.

Figure 127: SCSI Disk 2
13. Repeat step 12 for SCSI Disk 3. Refer Figure 13.
Figure 128: SCSI Disk 3
14. Click Begin Installation.

15. Under Shutdown the virtual machine menu, click Force off.
16. Click Show hardware details (bulb icon). Some additional changes are required before installation is started.
You should see the screen as shown in Figure 14.

Figure 129: Show hardware details
17. Login as root to the host and edit the configuration of newly created VM to confgure the two shared disks as
SCSI LUNs instead of SCSI disks. Execute the following command to view the state:
# virsh list --all

Id
Name State
----------------------------------------------------
emsvmpri shut off
18. Execute the following command to open the vi editor:
# virsh edit emsvmpri
19. Find all the occurrences of the following line:
<disk type='block' device='disk'>
And, replace them with the following line:
<disk type='block' device='lun'>
20. Press ESC and execute the following command to save and exit:

20.
:wq!
21. View and confirm the hardware details in the virt-manager GUI. The information should be similar as
displayed in Figure 15.
Figure 130: Hardware details
22. Click the Power on the virtual machine (right arrow icon) to start the .iso installation.
23. Click the Show the graphical console icon to view the console.
24. Type 1 and press Enter to start .iso installation. Refer Figure 16.

Figure 131: Begin installation
25. Once installation completes, you should see the reboot screen shown in Figure 17. ISO installation may take
about 10 minutes.
27. Browse to Show virtual hardware details and click IDE CDROM 1 option and click Disconnect to un-mount
the iso. Refer Figure 18.

30. Continue the procedure from step 1 of Performing EMS HA ISO Installation.
31. Once the VM on primary host is created successfully, repeat this procedure to create VM on secondary host.
Change the VM name appropriately, for example: emsvmsec.

To perform the installation of EMS Software Application on KVM for a HA setup, perform the following steps first on
the primary EMS VM followed by secondary EMS VM.
Press the Tab key to select the OK button and press the Space key to save the settings.
The EMS hostname is limited in length to 64 characters. The hostname can only contain
lowercase letters [a-z] and digits [0-9]. The hostname cannot start with a digit. Special
characters including hyphen are not allowed in hostname.

Figure 136: Hostname
b. Use the Arrow keys to select IP Configuration and press the Space key to configure IP address.
Select the eth0 interface for which you need to configure the IP Address. Use the Tab key to select
the OK button and press the Space key to configure IP address for eth0 network interface.

key to move the cursor to other parameter. Press the Tab key to select OK and press the Space key
to save IP Address details.

d. Use the Arrow keys to select Time Zone and press the Space key to configure the time zone. Select
the nearest time zone for the system and press the Tab key to select OK and press Space to save the
time zone settings.


3. Unmount the virtual disk as CD ROM by selecting Virtual Drives from the menu and clear the Image File
check box.
If the CD is not unmounted and for some reason the ISO boot menu options screen is displayed,
then click the Disconnect button and reboot the VM by clicking on CTRL+ALT+DEL from the Send
Key menu options.
The login screen appears:


b. Same letters
f. Dictionary words
The above procedure completes the RHEL 6.4 OS and EMS application installation on primary EMS HA
system. Similarly, you need to perform the RHEL 6.4 OS and EMS application installation on secondary EMS
HA system.
This section provides information for installing HA application and setting-up High-Availability deployment. This is
done by setting the values in the configuration file (vm.rac.conf) and executing the RACinstall_1 script.
EMS HA VM installation procedure is similar to EMS HA physical (HP G8) based installation. Only
difference is in some configuration parameters used for installation (for example, _public_interface is
eth0 for VM, instead of bond0)
EMS installation script (RACinstall_1) requires a configuration file. Create the configuration file by copying it from
a template file available under /export/home/pkg and then manually setting values for relevant fields. Use this

configuration file as input to installation script.
Perform the following procedure to configure the values for the template configuration files:

2. Navigate to the location cd /export/home/pkg .
3. Copy template configuration file to /tmp and rename it:
# cp rac.conf_VM.template /tmp/vm.rac.conf
# chmod +w /tmp/vm.rac.conf
4. Edit the vm.rac.conf template file.
For private IP, do not use the same private IP of the hypervisor.
# vi /tmp/vm.rac.conf

_ntpServer=
from)
_node01=

_node02=

_node01_public_ip=

_node02_public_ip=

_node01_public_vip=

_node02_public_vip=

_clusterName=
sonusVIP.IPv4=

ipv6Support=false



sonusVIP.IPv6=




# Leave blank. RAID array Controller IPs are not used in case of VM deployment
_array_controllerA_IP=
_array_controllerB_IP=
# Public interface name, leave at default value

_public_interface=eth0
# Private interface name, leave at default value

_private_interface=eth1

# Storage RAID type, not required for VM
_storage_type=
After updating the values, press the ESC key and enter :wq! to save the configuration.
The following section provides details about running the EMS installation scripts:
RACinstall_1 script
This script performs initial RAID and network related configuration across both nodes.
1. Navigate to the path /export/home/pkg, using the following command:
[root@emshp5vm1]# cd /export/home/pkg
2. Run the following command on the primary HA node:
[root@emshp5vm1 pkg]#./RACinstall_1 /tmp/vm.rac.conf

...
Generating and installing cluster-specific ssh keys for oracle .......... (ok)
3. After the script is successfully executed, you can proceed to the next step, which is EMSRACinstall script.
Perform the following procedure to create EMS partitions, install Oracle Clusterware and Oracle RAC on the primary
server.
Troubleshooting Installation Tip
During EMS installation, ignore the following errors, unless DB Instance creation fails. The following
/rdbms/<ORACLE_SERVICE_NAME>/$ORACLE_SID/trace
Error Codes:
ORA-00942
ORA-942
all/logs.

# ./EMSRACinstall
Checking dependencies ................................................... (ok)

Starting EMS installation on emshp5 ..................................... (ok)
Performing a FRESH installation of Insight EMS .......................... (ok)
...Command output cut for brevity...

Completed EMS installation on emshp5 .................................... (ok)
The Insight EMS HA installation for KVM is complete.
primary node at /var/sadm/install/logs. If there are errors during the installation, refer to RACinsta
ll_1.<id>.log, RACinstall_2.<id>.log and EMSinstall.<id>.log.The DB installation log files
are located at /opt/oracle/orasql/SIDB01 on the primary node.
After completing the EMS Installation, perform the mandatory post-installation tasks. For more details about
post-installation tasks, refer the section Performing Post-Installation Tasks.
EMS SWe DR Configuration for KVM

Overview
Disaster Recovery setup consists of a source site and target site, both deployed at a geographical different
locations. In case, if the source (primary database) Insight system is disabled, the target system (standby database)
can be switched to the production role, thus minimizing the downtime and data loss associated with the outage. The
EMS Software Version V09.03.00 installed virtually on KVM, supports Disaster Recovery (DR) setup for both
Standalone and High Availability (HA) systems.

CAUTION
The EMS Software-only V09.03.00 KVM deployed for a DR setup, must have same deployment type
(Standalone or High Availability) on source site and target DR site.
Following combination of DR setups are not supported:
The EMS V09.03.00 on KVM does not support different source and target DR site
combination. For example, source site having an HA setup and target DR site deployed
with Standalone (SA) system.
Both the source and target DR sites must be installed on KVM. The DR setup does not
support software-only installation (VMware or KVM) on one site and physical server-based
installation on other DR site.
Installing EMS Software for DR Setup
Performing EMS Software-only installation virtually for a DR setup is same as installation of EMS Software KVM for
Standalone and HA. There is one additional step to be performed for DR deployment. After installing EMS Software
on both the source and target DR site, execute the /opt/sonus/ems/conf/DR/manageDR setup command on
source DR site to (if EMS HA, run on primary node of source site) configure and synchronize the source (primary
DB) and target (standby DB) sites for replication.
The following table lists the high-level steps with corresponding links for installing EMS Software-only V09.03.00 on
KVM for a DR setup.
High-level Installation Steps using KVM for DR Setup
The high-level steps for installing EMS SA virtually on KVM for DR setup are listed in the following table.

Table 46: Installing EMS Software on KVM for a DR Setup
Step Task Task to be performed on DR Installing EMS Installing EMS High

Number Site (Source or Target) Standalone Server Availability Server
on KVM on KVM
1 Identify Source and Target DR Sites Installation Requirements Installation Requirements

Installation for Standalone for HA
Requirements
2 Perform Host Source and Target DR Sites Host Operating System Host Operating System
Operating System Installation for SA System Installation for HA System
Installation
3 Download Files Source and Target DR Sites Downloading ISO from Downloading Files from
from Salesforce SalesForce Salesforce
4 Create Virtual Source and Target DR Sites Creating EMS Virtual Creating Virtual Machine
Machine (VM) Machine Instance Instance for HA Systems
Instance
5 Perform EMS Source and Target DR Sites Performing EMS SA or IAS Performing EMS HA iso
Installation ISO Installation Installation
6 Install EMS HA Source and Target DR Sites N/A Installing EMS HA

Application application
7 Setup DR Source DR Site ONLY Setup Setup
8 Perform Source and Target DR Sites Performing post-installation Performing post-installation

Post-Installation tasks tasks
Steps
For more information about DR Operations, refer EMS DR Operations.
For more details about EMS Licensing details, refer the section Managing Licenses in User Guide.
Upgrading Insight EMS SWe on KVM
This section provides information on upgrading Insight EMS SWe on KVM.
Upgrading EMS SWe Standalone on KVM

Upgrading EMS SWe HA on KVM
Upgrading EMS SWe DR on KVM
Upgrading EMS SWe Standalone on KVM
EMS SWe INPLACE Upgrade on KVM

EMS SWe Kickstart Upgrade on KVM
This section provides information for upgrading EMS SWe Standalone (SA) on KVM using an INPLACE upgrade or
Kickstart upgrade.

ID/trace
Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700
EMS SWe INPLACE Upgrade on KVM
upgrade.
This step identifies the required upgrade files to be downloaded and how to prepare the files for upgrade.
Backup the EMS.
This step is used to manually backup EMS Data.
If the upgrade is not successful, then you can revert back to the previous EMS release by restoring the
backup manually. For more information, see Rollback EMS SA.
EMS SWe Kickstart Upgrade on KVM
The following summary outlines the key steps required to upgrade EMS standalone server using Kickstart upgrade.
Backup the EMS.

Performing KICKSTART Upgrade Procedure for EMS SA
Execute the following steps to perform a kickstart upgrade for EMS SA:
ID/trace
Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700

command:

file]


#


_ems_backup=

required.



remote server.

_backup_remote_IP=



on kickstarting the system, see EMS SWe Kickstart.
# rpm -qa SONSems

SONSems-V09.03.00-R000.x86_64

EMS SWe Kickstart

following command:
# virt-manager&
2. Right-click the Virtual Machine, you want to open, and click Open from the pull-down list.
Figure 141: Open VM
3. After the Virtual Machine opens, click Details in Toolbar and select IDE CDROM1 from the left pane and click
Connect.
A dialog box opens to select the ISO file.

Figure 142: VM Details
4. Choose the default selection of ISO Image Location and click Browse to select the ISO file location.
A screen opens to browse the EMS system for selecting the ISO file.
Figure 143: Choose Source Device or File
5. Click Browse Local to select the path of ISO from the EMS system.

Figure 144: Browse Local System to select ISO File
6. Locate and select the path from the respective directory in EMS system where the ISO file has been copied
and click Open.
Figure 145: Select EMS ISO
7. The selected ISO file is displayed in the dialog box. Click OK to enable EMS selecting the ISO when it is
rebooted.

7.
Figure 146: Choose Source Device or File
8. Select Boot Options from the left pane and from the pull-down menu next to Shut Down, select Reboot as
displayed in the following figure.
Figure 147: Reboot
9. After reboot, the following screen is displayed. Type 1 and press Enter.

9.
Figure 148: Begin Installation
10. Once installation is completed, you should see the reboot screen shown in Figure 10. ISO installation may
take about 10 minutes.
12. Browse to Show virtual hardware details screen. Select IDE CDROM 1 option and click Disconnect to
un-mount the iso. Refer Figure 11.


16. Specify a relevant Hostname using which you can easily identify the VM host.

17. Enter the IP Address, Subnet Mask, and Gateway details for the virtual interface.
18. Select the TimeZone where the VM host system is located from the list of time zones.

19. Enter the NTP Time-Server IP Address, to synchronize the time for the VM host system.

Login screen is displayed, after the EMS Application Software Suite is successfully installed on the VM host.
20. Login as root user to the EMS Software on the VM host system.
Change the password of the root user the first time you login to the EMS application.

This completes the EMS installation on the VM host system.
1. Install Insight EMS by performing the following:
a. Perform Insight Installation using old ISO. For more information, see " EMS SWe Kickstart".
b. Perform " Performing EMS Post-Installation Tasks".
$ ./sonusEms start

2.
9.2.1 Release and above backupFiles.tar


log

Upgrading EMS SWe HA on KVM
Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700
for upgrade.

1.
a. Perform EMS Installation using the old ISO. For more information, see " Kickstart the HP G8 Servers ".
b. Installing EMS HA Application and Configuring HA .
exp_data_manual.dmp



log
Upgrading EMS SWe DR on KVM

This section provides information on upgrading EMS SWe Standalone (SA) and HA for DR configuration on KVM.
Upgrading EMS SWe SA for DR Configuraton on KVM Upgrading EMS SWe HA for DR Configuraton on
KVM
Upgrading EMS SWe SA for DR Configuraton on KVM
configuration.
Backup the EMS.

source EMS system.
EMS system.
Upgrading EMS SWe HA for DR Configuraton on KVM

Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700

Common Administrative Tasks
EMS SA Administrative Tasks
For EMS SA administrative tasks, refer the section Insight Server Administration.
EMS HA Administrative Tasks
For EMS HA administrative tasks, refer the section EMS Server Administration for HA Linux.
EMS Database Tasks
For EMS SA database tasks, refer the section Insight Server Database Administration.
For EMS HA database tasks, refer the section Insight Server Database Administration for EMS HA.
Moving Virtual Machine (VM) License ID from one Physical Host to another
For more details about EMS Licensing details, refer the section Managing Licenses in User Guide.
This section provides details about moving VM to another physical hardware while keeping the same License ID
(UUID). The following are key criteria to which you need to adhere, before and after you move the VM to another
EMS system.
Same version of VM based EMS must be installed on the new hardware.

After License ID move is completed and new EMS is started up, the old VM based EMS must not be used.
Perform the following steps, to move VM to another physical hardware:

1. Shutdown the new EMS VM. Login to the new EMS VM as root using the following command:
#shutdown now -P
2. Login to the physical host, where the old VM is located, as root user, and get the value of UUID:
# virsh dumpxml <VM-name> | grep uuid
A command output similar to the following is displayed. The UUID value to use in the new VM is specified in
the command output.
<uuid>ef6b9dd1-202d-b0ec-57e9-8e80b1809768</uuid>
The virsh list-all displays names of all available VMs.
3. Login to the physical host where the new VM is located, as root user, and edit the VM configuration:
# virsh dumpxml <VM-name> > /tmp/<VM-name>.xml

# virsh undefine <VM-name>
a. Edit the /tmp/<VM-name>.xml file using vi editor.

b. Change the value of the uuid at the top of the file, replace with the value obtained in step 2.
c. Save the changes.
4. Redefine the VM with the udpated UUID:
# virsh define /tmp/<VM-name>.xml

# rm /tmp/<VM-name>.xml
5. Start the new VM, using the following command:
# virsh start <VM-name>
6. After VM is fully started, login as root to the VM EMS and run the sonusLicenseKey command.
# /opt/sonus/ems/conf/sonusLicenseKey

Verify that the value shown is the same as the value from the old VM on the other physical host.
Verify that the value remains the same even after a VM reboot.
7. Shutdown and power off the old EMS VM.
Old EMS VM should no longer be started, after the UUID has been migrated to new VM.
If old EMS VM is still running, then login to the EMS as root and run the following command:
# shutdown now -P
Deleting EMS SA VM
This procedure describes the steps of deleting the SA VM. This section is only applicable, when you do not want to
use the VM anymore. You would not normally need to perform this procedure.
Deleting the SA VM, results in data loss on disks.
Perform the following steps, to delete the SA VM:

2. Execute the following command to delete the VM:
# /tmp/vm/setup-ems-kvm.sh -t sa -a delete
This completes the SA VM deletion procedure.
Deleting EMS HA VM
This procedure describes the steps of deleting the HA VMs. This section is only applicable, when you do not want
to use the VM anymore. You would not normally need to perform this procedure.
Deleting the HA VM, results in data loss on disks.
Perform the following steps, to delete the HA VM:

2. Execute the following command to delete the VM:
# /tmp/vm/setup-ems-kvm.sh -t ha -a delete
This completes the HA VM deletion procedure.

Insight EMS SWe on VMware ESXi Platform can be installed for Standalone and HA deployment modes from EMS
Software Release 9.3.0 onwards. This section provides information for installing EMS SWe on VMware ESXi
Platform for SA, HA and DR deployment modes.
Insight EMS V09.03.00 is the first release of EMS SWe on VMware ESXi. The EMS SWe VMware upgrade
procedure is to support the upgrade of EMS on VMware with 9.3.0 to EMS Releases above 9.3.0 release.
This page contains the following sub-pages:
Hardware and Software Requirements for Insight EMS SWe on VMWare

Installing Insight EMS SWe on VMware ESXi
Upgrading Insight EMS SWe on VMware ESXi
Common Administrative Tasks for EMS VMware
Hardware and Software Requirements for Insight EMS SWe on VMWare
To install and configure the EMS software edition, ensure that the Virtual Machine (VM) host meets the
recommended hardware, server platform, and software requirements.
The hardware and software settings are intended to ensure optimum EMS SWe stability and performance
for small and large configuration. If these settings are not used, EMS SWe system may not perform as
expected.
Depending on the SA or HA deployment type of installation, refer the following installation requirement
section:

This section provides information for small and large standalone and HA deployment configurations:
Minimum CPU rating that is supported is 2.0 GHz. Sonus will not support users with CPUs below 2.0 GHz.
Standalone Configuration
Configuration Type vCPU vMemory (GB) vHDD (GB) vNIC
Small 4 cores 8 300 1
Large 12 cores 32 900 1
High Availability (HA) Configuration
Configuration vCPU vMemory vHDD (GB) SAN Disk vNIC

Type (GB)
Small 4 8 250 GB (VM 1), 250 GB 90 GB (ASM), 60 GB 2 (1 Public + 1

cores (VM 2) (EMS) Private)

Large 12 32 250 GB (VM 1), 250 GB 600 GB (ASM), 300 GB 2 (1 Public + 1
cores (VM 2) (EMS) Private)
Here, the vCPU is independent of the underlying hyperthreaded core hardware.
Installation Requirements for Standalone (SA) Deployment on VMware
This section provides details about the software and hardware requirements for performing SA installation on
VMware:
Management (ASM) files. The disk space and partitioning requirements, are different for 'small' and 'large'
configuration.
The EMS Software Edition installed on a virtualized environment, supports both local storage or remote
SAN storage (iSCSI LUN) to store the data. If a direct-attached RAID is to be used, ensure that the RAID
disks (LUNs) of required sizes are exposed on the host.
are:
SCSI disks.
Installation Requirements for High-Availability (HA) Deployment on VMware
This section provides hardware and software requirement details for installing EMS SWe for HA deployment on
VMware.
Management (ASM) files. The disk space and partitioning requirements are different for 'small' and 'large'
configuration.
The EMS Software Edition installed on a virtualized environment supports both local storage or remote SAN
storage (iSCSI LUN) to store the data.

Network Requirements
Network connections (public and private) between the two VM hosts need to be established just as in the case of a
physical (HP G8) based HA setup. Configure the private and public network connections between hosts as shown in
Cabling and Network Connectivity for Insight EMS High Availability Cluster . Instead of direct-attached RAID, SAN
network connections need to be established between the two VM hosts to the SAN switch.
EMS HA Solution
Relevant network connections (separate from public/private HA network) and bonding must be setup for the storage
network to enable SAN storage.
are:
SCSI disks.
Ensure that both the HA nodes are pointing to the same shared LUN on the SAN.
Shared disks must be displayed as SCSI disks within the VM. For an HA setup, execute the scsi_id
command on both nodes and ensure that it displays the same value for shared disk on both nodes.
For better understanding the usage of each disks for EMS HA (small or large configuration), refer the following table:
Table 49: Disks and Usage for EMS HA Setup
Disk Disk Size for Disk Size for Usage

HA Large HA Small
Configuration Configuration
Disk 250 GB (VM 1), 250 GB (VM 1), Used to store the OS and EMS packages. This disk can be either a local or
1 250 GB (VM 2) 250 GB (VM 2) a remote disk (iSCSI LUN).
Disk 300 GB (EMS) 60 GB (EMS) It is a shared disk used to store EMS files. The remote disk can be used
2 using iSCSI or direct attached (example IBM DS3524/IBM V3700) FC
connections.
Disk 600 GB (ASM) 90 GB (ASM) It is a shared disk used to store Oracle ASM files. The remote disk can be
3 used using iSCSI or direct attached (example IBM DS3524/IBM V3700) FC
connections.
The following is the Host Hypervisor VMware ESXi software requirement.
VMware ESXi Requirements
The VMware ESXi requirments are listed in the following table.

The vSphere ESXi server software needs to be first installed on the host, before proceeding with VM
creation.
Table 50: Host Hypervisor VMware Software Requirements
Software Version
vSphere ESXi 5.1.0 or above
vSphere Client 5.1.0 or above
EMS Application Requirements
Table 51: Software Requirements
Configuration Version
EMS SWe V09.03.0R000
Installing Insight EMS SWe on VMware ESXi
This section provides information about installing EMS SWe on VMware ESXi.
This page contains the following sub-pages:
EMS SWe Standalone or IAS Installation Procedure for VMware ESXi Platform
EMS SWe HA Installation Procedure for VMware ESXi Platform
EMS SWe DR Configuration for EMS VMware
EMS SWe Standalone or IAS Installation Procedure for VMware ESXi Platform
This page provides Standalone EMS or IAS Software only installation procedure for Linux on VMware ESXi
platform. If you are installing EMS Software or IAS virtually for a standalone deployment on VMware ESXi, refer to
the following sections:
Perform the following steps for installing IAS. After completing IAS installation, ensure that you run
remoteIasInstall.sh script on EMS server and provide the IAS ip address. For more information, refer the
section Installing Insight Application Server.
Installing EMS SA or IAS SWe Software on VMware ESXi Platform

Installing VMware ESXi
Creating Virtual Machine Instance for EMS Standalone or IAS
Downloading EMS Standalone SWe Software Package From SalesForce
Uploading EMS Standalone SWe Software Image to Datastore
Mounting the ISO Image on VMware
Installing EMS Standalone Application or IAS on the VM Instance

During EMS SA installation, ignore the following errors, unless DB Instance creation fails. The following
Error Codes:
ORA-00942
ORA-942
Installing EMS SA or IAS SWe Software on VMware ESXi Platform
Before proceeding, ensure that the hardware and software requirements to install EMS SA or IAS are met.
The following summary outlines the key steps required to install EMS Standalone or IAS sofware-only application on
a VMware ESXi Platform.
This step creates the Virtual Machine (VM) instance for installing EMS SA on VMware ESXi platform.
Downloading EMS Standalone or IAS SWe Software Package From SalesForce
This step shows you what and how to download the EMS Standalone package from SalesForce.
Uploading EMS Standalone or IAS SWe Software Image to Datastore
This step shows you how to upload the EMS SA software image to datastore.
This step shows you how to mount the ISO image on VMware.
This step shows you how to install the EMS SA application or IAS on VMware.
If you are doing an IAS installation, this step is not applicable. Post-installation tasks are only
performed for EMS installation.
Before creating a Virtual Machine and installing EMS SWe images, install VMware ESXi on the host or hosts
allocated for SWe. Please refer to VMware documentation for installing and configuring VMware ESXi.
VMware ESXi version 5.1 or above is recommended for EMS.
References:

Refer to VMware Compatibility Guide for a list of VMware supported Intel processors.
Refer to ESXi hardware requirements to ensure the VMware supported Intel processors meet ESXi hardware
requirements.
Refer to vSphere Client and vSphere Web Client Software Requirements to ensure that your operating
system supports the vSphere Client
Installation Checklist
Prior to installing EMS software, you need to collect the information listed below.
Parameter Description Examples of

Value for
your system
(fill in)
Primary The Primary Network Interface (PNI) of the system. eth0

network
interface
name
Host name The name which identifies the system on the network. ems1
The EMS hostname is limited in length to 64 characters. The hostname can

only contain lowercase letters [a-z] and digits [0-9]. The hostname cannot
start with a digit. Special characters including hyphen are not allowed in
hostname.
IP address The Internet Protocol (IP) address for the network interface. 10.9.9.103
Default The node on a TCP/IP network that serves as an access point to another network. 10.9.9.1
router
of subnet
NTP The Network Time Protocol server to which the system containing VM synchronizes the time. 10.9.9.5
DNS The DNS servers of this network. 10.9.9.6
Timezone The timezone where the VM host system is located. Asia/Kolkata
To install EMS SWe or IAS on a virtual machine (VM), you need to first create a VM and allocate its resources (for
example CPU, memory, and NICs), as well as configure a datastore to contain the operating system and EMS SWe
application software.
1. Login as root on the VMware host using the VMware vSphere client.
a. Enter VMware host machine IP Address.
b. Enter the root password.

b.
Figure 158: VMWare VSphere Client Login
The vSphere Client main window appears.

2. After logging in, right-click the specified IP address on right-pane, and select New Virtual Machine from the
drop-down list.

Figure 159: The Getting Started Tab.
3. Click Custom in the Configuration window, and click Next.

Figure 160: Create New Virtual Machine - Custom Configuration
4. Provide a Name for EMS VM. For example, ems_SA_smallconfig or ems_SA_LargeConfig through
which you can identify the VM configuration easily. The name can be up to 80 characters. Click Next.

Figure 161: EMS SWe VM Name
5. From the Storage screen, select the appropriate SAN datastore that you have previously created and click
Next. This SAN is required to store all log-related data files.
The datastore must be previously created with an appropriate name.

Figure 162: Destination Storage for VM Files.
6. Click Virtual Machine Version: 8 and click Next.

Figure 163: Selecting Virtual Machine Version.
7. From the Guest Operating System screen, make the following selections, and then click Next.
a. Click Linux as the Guest Operating System.
b. Select Red Hat Enterprise Linux 6 (64-Bit) from the Version drop-down menu.

Figure 164: Guest Operating System.
8. From the CPUs screen, make the following selections, and click Next. The CPU, memory configuration, and
disk space size for small and large standalone configuration is different.
a. For creating VM with small configuration, select:
i. Number of virtual sockets: 1.
ii. Number of cores per virtual socket: 4.
iii. Click Next.

Figure 165: vCPU Configuration for Small Configuration
Or
b. For creating VM with large configuration, select:
i. Number of virtual sockets: 1
ii. Number of cores per virtual socket: 12
iii. Click Next.

Figure 166: vCPU Configuration for Large Configuration
9. From the Memory screen, assign memory for the virtual machine, and click Next. The minimum memory
required for small and large configuration is different.
a. For small configuration, select:
i. Memory Size: 8 GB
ii. Click Next.

Figure 167: vMemory Configuration for Small Deployment
Or
b. For large configuration, select:
i. Memory Size: 32 GB
ii. Click Next.

Figure 168: vMemory Configuration for Large Deployment
10. Define virtual machine network interface connections (NICs) using the following options from the drop-down
menus. Then click Next to continue.

Figure 169: Virtual Network Interface Cofiguration.
11. From the SCSI Controller screen, click VMware Paravirtual as the SCSI Controller option, then click Next to
continue.

Figure 170: Selecting SCSI Controller.
12. From the Select a Disk screen, click the Create a new virtual disk option, then click Next to continue.

Figure 171: Create a New Virtual Disk
13. From the Create a Disk screen, make the following selections:
a. For standalone small configuration, specify Disk Size as 300 GB, and perform the following steps to
create a disk:
i. In the Capacity section, assign a minimum of 300 GB of disk space.
ii. In the Disk Provisioning section, click the Thick Provision Eager Zeroed option.
iii. In the Location section, click Store with the virtual machine.
iv. Click Next.

Figure 172: Specifying vDisk Capacity for Small Configuration
Or
b. For standalone large configuration, specify Disk Size as 900 GB, and perform the following steps to
create a disk:
i. In the Capacity section, assign a minimum of 900 GB of disk space.
ii. In the Disk Provisioning section, click the Thick Provision Eager Zeroed option.
iii. In the Location section, click Store with the virtual machine.
iv. Click Next.

Figure 173: Specifying vDisk Capacity for Large Configuration
14. From the Advanced Options screen, keep the default value SCSI (0:0) as is and click Next. The default
virtual device node is SCSI (0:0).

Figure 174: Advanced Options.
15. From the summary screen, review your VM settings and click Finish. If needed, click Back to return to the
screen in question and make necessary adjustments.

Figure 175: Verify VM Configuration.
16. When you are satisfied with your settings, click Finish to complete the VM creation.
The virtual machine is created under host IP address with the specified configuration.
Figure 176: Recent Tasks Progress Bar
17. After VM is created, you must manually enable autostart and autostop of the Virtual Machine. Enabling the
autostop/autostart of Virtual Machine is useful, in scenarios where power is lost and later regained. This
setting of VM helps autostart of VMs when the host machine is powered ON.
To autostart the VM, perform the following steps:
a. Select the host IP address from left-pane and click Configuration Tab. From the right-pane, click
Virtual Machine Startup/Shutdown displayed in Configuration Tab.
The following screen displayed.

Figure 177: Virtual Machine Startup/Shutdown
b. Click Properties link displayed towards the top-right window.

Select the Allow virtual machine to stat and stop automatically with the system check box.
The Startup Order screen is enabled.
Figure 178: Enabling Auto Startup and Auto Shutdown of VM
c. Select the VM, which you want to automatically start and click Move Up.
The selected VM is displayed underneath Automatic Startup.

Figure 179: Moving VM to AutoStartup
d. Click OK.
This completes the autostartup and autoshutdown settings for the Virtual Machine.
The EMS SWe application is available as a software package downloadable from the SalesForce customer portal.
2. Click software bundle WL93 to view its contents, and then click Request Download.
4. When the Request Status on the SOFTWARE REQUESTS page displays Download Available, click the
links in the WL93 software bundle to download the files.
5. Download the EMS ISO image ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64 to your local
desktop from the Sonus Salesforce Customer Portal.
Uploading EMS Standalone SWe Software Image to Datastore
This section describes the steps to upload the EMS ISO image from your system to the SAN datastore. After
downloading the EMS ISO package from SalesForce, you need to upload the ISO file to the SAN datastore. After
the ISO image is available on SAN, it can be used to install EMS on VMs.
Ensure you have downloaded the EMS ISO file from SalesForce to your system, before executing the
following steps. For details, on how to download ISO from SalesForce, refer to the section Downloading
EMS SA SWe Software Package from Salesforce.
To upload the EMS Software ISO image to SAN datastore, perform the following steps:
1. Login as root user on the VMware host using the VMware vSphere client.
2. In the main vSphere client window, select the VM from the left pane.
3. Choose the Summary tab on the right pane, and right-click on the SAN datastore name, select Browse
Datastore... from the drop-down menu.

3.
Figure 180: Browse Datastore
4. In the Datastore Browser window, click Upload files to this datastore.
Figure 181: Selecting Datastore ISO File.
5. Select the Upload File... option.

Figure 182: Upload File to SAN Datastore
6. Select the ISO from your system where it was downloaded from SalesForce. Click Open to upload it to the
SAN Datastore.
Figure 183: Select ISO File
A warning is displayed, indicating if the same file-name exists on the target, it will be replaced.

Figure 184: Upload/Dowload Operation Warning
The Uploading... window pops up and shows the status of upload. Wait for the ISO to get uploaded on SAN
datastore.
Figure 185: Upload Progress Window
After the ISO is uploaded successfully, the following figure is displayed.
Figure 186: ISO Uploaded Successfully

The following steps describe how to mount the EMS iso image on a VM you have created:
1. Select the VM from the left and choose Edit Settings.
Figure 187: Edit VM Settings
2. Select the CD/DVD drive 1 option and select the Connect at power on check box. Click the Datastore ISO
file option and click the Browse button.

Figure 188: Enabling Connect at Power On
3. In the Browse Datastores window, select SAN datastore.

4. Select the EMS iso file uploaded earlier.

Figure 190: Selecting SAN Datastore ISO File
5. Click OK to close the Browse Datastores window.

6. Click OK to close the Virtual Machine Properties window.

Figure 191: Closing VM Properties Screen
To perform the installation of EMS Software Suite on VMware for a Standalone setup or IAS, perform the following
steps:
1. Ensure that the Virtual Machine is started on the VMware ESXi server, before performing installation. If the
VM is not started, you need to start the VM.
a. To start the VM, click Power on the virtual machine highlighted in the following figure:

Figure 192: Power-on Virtual Machine
b. After VM is powered-on, right-click on the machine-name and select Open Console.
Figure 193: Open Console
2. After the VM is started, the EMS Installation Option screen is displayed. Enter 1, to proceed with EMS
Installation.
To perform Insight Application Server (IAS) installation, enter 2 and proceed with IAS installation.

To toggle between the console and other screens, press the CTRL+ALT keys together.
Figure 194: EMS Installation Options
The RHEL Operating System installation is performed on the VM as shown in the following figure.

Figure 195: RHEL Installation
After the RHEL OS is installed, post-installation checks are performed as displayed in the following figure.

Figure 196: Post-Installation Checks
After RHEL is installed successfully and post-installation checks are successfully performed, the Reboot
screen is displayed.
Release the locks on the mounted ISO, before rebooting. To disconnect the mounted ISO,
disconnect the ISO from CD/DVD by performing step 3.

Figure 197: Reboot
3. To release the VM locks on the mounted ISO, perform the following steps:
a. Right-click on the machine-name and select Edit Settings from the menu.
b. Select CD/DVD drive 1 (edited) and clear the Connect at power on check box.
Figure 198: Uncheck Connect at Power on
c. A confirmation message is displayed as shown in the following figure. Click Yes and click OK, to
disconnect the ISO.

c.
Figure 199: Disconnect CD-ROM Confirmation message
d. Go back to the Reboot screen and press the Enter key.

After reboot, the Sonus Network Configuration screen is displayed.
4. Press Enter to configure Hostname.
5. Specify a relevant Hostname using which you can easily identify the VM host and click OK.

Primary DNS Server IP Address, Secondary DNS Server IP Address and DNS Search Path are
optional.
6. After configuring host name, Sonus Network Configuration screen is displayed. Select IP Configuration
using the arrow keys and press Space.

Figure 202: IP Configuration
a. Select the IP format (IPv4/IPv6) by which you want to configure IP address for eth0. Click OK.

Figure 203: IP Format (IPv4/IPv6)
b. Enter the IP Address, Subnet Mask, and Gateway details for the virtual interface.
7.

7. From the Sonus Network Configuration screen, select the Time Zone using the arrow-keys and press the
Space key to configure time zone.
a. Select the Time Zone where the VM host system is located from the list of time zones.
8. After configuring Time Zone, Sonus Network Configuration screen is displayed. Select Time Server using
arrow keys to configure the NTP Time server.

Figure 206: Timeserver
a. Enter the NTP Time-Server IP Address, to synchronize the time for the VM host system and click OK.

Figure 207: NTP TimeServer Configuration Screen
9. Login screen is displayed, after the EMS Application Software Suite and Oracle database are successfully
installed on the VM Host. Login as root user and default password 'sonus' to the EMS Software on the VM
host system.

10. The first time you login as root user, after EMS installation, you are enforced to change the default
password 'sonus'. Specify the current password and the New password that you want to set.
Ensure that new password is not a dictionary word or too similar to the current password.

Figure 209: Change Password
After successfully installing EMS, the following screen is displayed.

Figure 210: EMS Installation Completion
This completes the EMS Installation on VMware virtual machine.
After completing the EMS Installation, perform the mandatory post-installation tasks. For more
details about post-installation tasks, refer the section Performing Post-Installation Tasks.
Based on your requirements, obtain the required license from Sonus and install the licenses using
License Manager. For more information about how to install Licenses, refer the License Manger
section in EMS User Guide.
EMS SWe HA Installation Procedure for VMware ESXi Platform
This page provides EMS HA Software only installation procedure for Linux on VMware ESXi platform. EMS Software
only (SWe) for HA deployment can be installed on VMware for both small and large configurations. If you are
installing EMS HA Software virtually on VMware ESX, refer to the subsequent sections.
Ignore the following errors, unless DB Instance creation fails. The following errors are seen on trace/alert
Error Codes:
ORA-00942
ORA-942
Installing EMS HA SWe Software on VMware ESXi Platform

Creating Virtual Machine Instance for EMS HA (Primary and Secondary)
Downloading EMS HA SWe Software Package from Salesforce
Uploading EMS SWe HA Software Image to Datastore
Mounting HA ISO Image on VMware
Installing EMS SWe for HA
Installing EMS HA Application on VMware
Installing EMS HA SWe Software on VMware ESXi Platform
Before proceeding, ensure that the hardware and software requirements to install EMS HA are met.
The following summary outlines the key steps required to install EMS HA sofware-only application on a VMware
ESXi Platform.
This step creates the Virtual Machine (VM) instance for installing EMS HA on VMware ESXi platform.
Downloading EMS HA SWe Software Package From SalesForce
This step shows you what and how to download the EMS HA package from SalesForce.
Uploading EMS HA SWe Software Image to Datastore
This step shows you how to upload the EMS HA software image to datastore.
This step shows you how to mount the ISO image on VMware.
This step shows you how to install the EMS HA application on VMware.
Before creating a Virtual Machine and installing EMS SWe images, install VMware ESXi on the host or hosts
allocated for SWe. Please refer to VMware documentation for installing and configuring VMware ESXi.
VMware ESXi version 5.1 or above is recommended for EMS.
References:
Refer to VMware Compatibility Guide for a list of VMware supported Intel processors.
Refer to ESXi hardware requirements to ensure the VMware supported Intel processors meet ESXi hardware
requirements.
Refer to vSphere Client and vSphere Web Client Software Requirements to ensure that your operating

system supports the vSphere Client
Prior to installing Insight HA system, collect and record the values for the system parameters shown in the table,
System Information required for Insight HA Installation.
All public IP addresses except DNS IP and iLO IP should be configured in same subnet.
The configuration information given below is tested in the lab condition and do not accurately portray a
properly configured system.
Parameter Value for your system (fill in) Examples
Cluster Configuration
Cluster The name of the cluster. emsha1

Name
The cluster name must be at least one character long and no

more than 15 characters in length, must be alphanumeric, and
may contain hyphens.
The name of the cluster can only contain lowercase letters [a-z], digits [0-9], and
hyphen [-].
The cluster name cannot start with a digit or hyphen, and cannot end with a
hyphen.
Cluster A virtual IP address used to uniquely connect to the EMS (owned by whichever 10.54.159.2
VIP server is active).
IPv6 A virtual IPv6 address used to uniquely connect to the EMS (owned by whichever fd00:10:6b50:4020::56/62
Cluster server is active).
VIP
(optional)
Gateway The IP address of the gateway. 10.54.159.1
of subnet
DNS The DNS servers of the network. 10.54.163.1

Servers
10.54.163.2
NTP The Network Time Protocol server. 10.128.254.68

Server

SCAN The first IP address used by the Oracle SCAN (single client access name) 10.54.159.200
Address 1
SCAN The second IP address used by the Oracle SCAN (single client access name) 10.54.159.201
Address 2
SCAN The third IP address used by the Oracle SCAN (single client access name) 10.54.159.202
Address 3
Hostname The name which identifies the system on the network. wfdems01a

Address
IPv6
Address
(Optional)

Address
required.
Hostname The name which identifies the system on the network. wfdems01b

Address

IPv6
Address
(Optional)

Address
required.
To install EMS SWe for HA setup, you need to create new virtual machine, each on two (2) separate physical
systems. The VMs must be created on two separate physical hosts to avoid single point of failure, in case one of the
system goes down. The following sub-sections describe how to create new Virtual Machine (VM) on VMware ESX
for primary and secondary systems.
Creating New HA VM as a Primary Host
Perform the following steps to create new virtual machine on VMware ESX server, using the VMware Client GUI.
The new VM created is configured to act as a primary host for HA setup. For non-primary host, a new VM is created
on separate physical system, which performs the role of non-primary EMS.
VMs that will act as EMS HA nodes, must be installed on two separate physical hosts for redundancy. First,
you must create a new VM for the primary host for HA setup.
1. Using VMware vSphere client, login to the host machine where VMware is installed.
2. You will see the machine IP address on the left pane.
3. Right-click on the IP address and choose New Virtual Machine.
4. Click the Custom option and click Next.

Figure 211: Custom VM Selection
5. Name the new VM, for example, ems_ha_small_primary, and click Next.

6. Choose the SAN Datastore as the destination for VM files. You should have previously created this
datastore; click Next.

Figure 213: SAN Datastore
7. Click Virtual Machine 8 as the VM version. Click Next.

Figure 214: Version 8
8. Click Linux as the Guest OS. RHEL 6 (64-bit) is selected by default. Click Next.

Figure 215: RHEL 8
9. Mention the number of cores per virtual socket, based on small or large configuration.
a. For small configuration, choose 1 virtual socket and 4 cores per virtual socket.
b. For large configuration, choose 1 virtual socket and 12 cores per virtual socket.
c. Click Next.

Figure 216: CPU Core Specifications for Small Config
10. Mention the memory size based on small or large configuration.

a. For small configuration, choose 8 GB memory size.
b. For large configuration, choose 32 GB memory size.
c. Click Next.

Figure 217: Memory Size for Small Configuration
11. Choose 2 NICs. Specify NIC 1 as Public Network and NIC 2 as Private Network, in that order. Leave
Adapter as VMXNET3 (default). Click Next.

Figure 218: NIC
12. Click VMware Paravirtual as the SCSI controller. Click Next.

Figure 219: VMware Paravirtual
13. Click Create a new virtual disk and click Next.

Figure 220: Create New Virtual Disk
14. Specify the following options for creating a disk and click Next:
Disk Size: Choose 250 GB.
Disk Provisioning: Click Thick Provision Eager Zeroed.
Location: Click Store with the virtual machine.

Figure 221: Disk Size: 250 GB
15. Perform the following advanced options selection for Virtual Disk:
a. Leave the Virtual Device Node at the default SCSI (0:0).
b. Leave Mode at the default (The Independent check box is cleared by default).
c. Click Next.

Figure 222: Virtual Device Node
16. In the Ready to Complete screen, select Edit the virtual machine before completion. Click Continue.

Figure 223: Ready to Complete: Edit VM Settings
17. For adding the first shared disk of size 600 GB, click the Add... button in the Virtual Machine Properties
screen.

Figure 224: Edit Configuration
18. Choose Hard Disk as the Device Type. Click Next.

Figure 225: Hard Disk Selection to add Shared Disk
19. Click Create a new virtual disk. Click Next.

20. Specify the shared disk size based on small or large configuration:
a. Disk Size: Based on large or small configuration, specify disk size as per the following specification:
For large configuration: Choose 600 GB.
or
For small configuration: Choose 90 GB.
b. Disk Provisioning: Click Thick Provision Eager Zeroed.
c. Location: Click Specify a datastore or datastore cluster.
d. Click Browse.

21. Select SAN as the datastore and click OK.
Figure 228: SAN Datastore selection

The following screen displays the shared disk to be stored on SAN. Click Next.
Figure 229: Shared Disk 90 GB SAN Datastore Selection
22. Select SCSI (1:0) for Virtual Device Node.

23. For Mode, select Independent and click Persistent. Click Next.

Figure 230: Configure Disk Mode as Persistent
24. Click Finish to complete the creation of the first shared disk.

Figure 231: Finishing first shared disk creation
25. Perform the following SCSI controller settings, to allow virtual disk to be used simultaneously across both the
VMs located on each physical machine.
a. Select New SCSI Controller from the Virtual Machine Properties page.
b. Click Physical for SCSI Bus Sharing option.
c. Click Finish.

Figure 232: Setting Bus-sharing as Physical
26. Wait for the Create virtual machine task at the bottom of the client window, to be of status Completed. It may
take a little while.

Figure 233: VM Creation completion
27. Now the second shared disk is added. For small configuration, specify the disk size as 60 GB and for large
configuration specify the disk size as 300 GB.
28. Right-click the new VM just created and click the Edit settings option from the pop-up menu.

Figure 234: Edit Settings
29. In the Virtual Machine Properties window, click Add....

Figure 235: Add Hardware

Figure 236: Select Hard Disk
31. Click Create a new virtual disk. Click Next.

32. Specify the disk size, based on small or large configuration:

a. Disk Size: Based on large or small configuration, specify disk size as per following specification:
For large configuration: Choose 300 GB.
or
For small configuration: Choose 60 GB.
c. Location: Click Specify a datastore or datastore cluster.
d. Click Browse.

33. Select SAN as the datastore and click OK.

34. The following screen displays the shared disk to be stored on SAN. Click Next.
35. Select SCSI (1:1) for Virtual Device Node.


37. Click Finish to complete the creation of the second shared disk of size 300 GB.


39. Wait for the Reconfigure virtual machine task at the bottom of the client window, to be of status Completed. It
may take a little while.

Figure 244: Complete Primary VM creation
Follow instructions to upload the EMS ISO image to the SAN datastore. For more information about
how to upload, refer to Uploading EMS SWe HA Software Image to Datastore. Then mount the iso
as per the steps specified and start the VM to initiate the EMS installation. For more information
about mounting an ISO, refer to Mounting HA ISO Image on VMware.
40. The following settings need to be performed on both primary and secondary hosts, and will cause the VMs to
be automatically started up after a host reboot.
Enabling the autostop/autostart of Virtual Machine is useful, in scenarios where power is lost and later
regained. This setting of VM helps autostart of VMs when the host machine is powered ON.
To autostart the VM, perform the following steps:
a. Select the host IP address from left-pane and click Configuration Tab. From the right-pane, click
Virtual Machine Startup/Shutdown displayed in Configuration Tab.
The following screen displayed.

Figure 245: Virtual Machine Startup/Shutdown
b. Click Properties link displayed towards the top-right window.

Select the Allow virtual machine to stat and stop automatically with the system check box.
The Startup Order screen is enabled.
Figure 246: Enabling Auto Startup and Auto Shutdown of VM
c. Select the VM, which you want to automatically start and click Move Up.
The selected VM is displayed underneath Automatic Startup.

Figure 247: Moving VM to AutoStartup
d. Click OK.
This completes the autostartup and autoshutdown settings for the Virtual Machine.
Creating New HA VM as a Secondary Host
After creating the new VM for primary host, create a new VM for secondary host. For secondary host, a new VM is
created on separate physical system, which performs the role of secondary EMS.
VMs that act as EMS HA nodes, must be installed on two separate physical hosts for redundancy. Ensure
that VM for primary system is already created, before you create a VM for secondary system.
Perform the following steps, to create a new VM for secondary host:
1. Using VMware vSphere client, login to the host machine where VMware is installed.
2. You will see the machine IP address on the left pane.
3. Right-click on the IP address and choose New Virtual Machine.
4. Click the Custom option and click Next.

5. Name the new VM, for example, ems_ha_small_secondary, and click Next.

6. Choose the SAN Datastore as the destination for VM files. You should have previously created this
datastore; click Next.

Figure 250: SAN Datastore
7. Click Virtual Machine 8 as the VM version. Click Next.

Figure 251: Version 8
8. Click Linux as the Guest OS. RHEL 6 (64-bit) is selected by default. Click Next.

Figure 252: RHEL 8
9. Mention the number of cores per virtual socket, based on small or large configuration.
a. For small configuration, choose 1 virtual socket, and 4 cores per virtual socket.
b. For large configuration, choose 1 virtual socket, and 12 cores per virtual socket.
c. Click Next.

Figure 253: CPU Core Specifications
10. Mention the memory size based on small or large configuration.

a. For small configuration, choose 8 GB memory size.
b. For large configuration, choose 32 GB memory size.
c. Click Next.

Figure 254: Memory
11. Choose 2 NICs. Specify NIC 1 as Public Network and NIC 2 as Private Network, in that order. Leave
Adapter as VMXNET3 (default). Click Next.

Figure 255: NIC
12. Click VMware Paravirtual as the SCSI controller. Click Next.

Figure 256: VMware Paravirtual
13. Click Create a new virtual disk and click Next.

14. Specify the following options for creating a disk:

a. Disk Size: Choose 250 GB.
c. Location: Click Store with the virtual machine.
d. Click Next.

Figure 258: Disk Size: 250 GB
15. Perform the following advanced options selection for virtual disk:
a. Leave the Virtual Device Node at the default SCSI (0:0).
b. Leave Mode at the default (The Independentcheck box is cleared by default).
c. Click Next.

Figure 259: Virtual Device Node
16. In the Ready to Complete screen, select the Edit the virtual machine before completion. Click Continue.

Figure 260: Ready to Complete: Edit VM Settings
17. For adding the first shared disk of size 600 GB, click the Add... button in the Virtual Machine Properties
screen.

Figure 261: Edit Configuration

Figure 262: Hard Disk Selection to add Shared Disk
19. Click Use an existing virtual disk. Click Next.

20. Click the Browse ... button to choose the disk file path.

Figure 264: Browse to choose disk file
21. In the browse window, select SAN datastore path. Click Open.
22.

22. Select the directory named after the primary host VM (for example, ems_ha_smallconfig_primary).
23. Shared virtual disks configured, while creating VM for primary are displayed. Select the appropriate VM disk
name based on the disk size, for example, ems_ha_smallconfig_primary_1. Click OK.
Figure 267: Virtual Disk File selection
24. The Disk File Path is displayed as shown in the following figure. Click Next.

Figure 268: Disk File Path
25. Choose SCSI (1:0) for the Virtual Device Node option.

Figure 269: Virtual Device Node Option
27. Click Finish.

Figure 270: Disk 1 Completion
28. In the Virtual Machine Properties screen, select the New SCSI Controller option (second option from bottom)
and click Physical for the SCSI Bus Sharing option. Click Finish.

Figure 271: SCSI Bus Sharing Physical
29. Wait for the Create virtual machine task at the bottom of the client window, to be of status Completed. It may
take a little while.
30. Add the second shared disk, by executing following steps:
a. Right-click on the newly created VM and click the Edit virtual machine settings option.
b. Click the Add... button in the Virtual Machine Properties window.

Figure 272: Add Virtual Disk
31. Choose Hard Disk for the device type. Click Next.

32. Click the Use an existing virtual disk option. Click Next.

Figure 274: Use existing virtual disk
33. Click the Browse... button to choose the disk file path.

34. In the browse window, choose the SAN datastore path.
35.

35. Select the directory named after the primary host VM (for example, ems_ha_smallconfig_primary)
Figure 277: Folder selection
36. Choose the file name depicting disk size for the second share disk. For example, in this directory, file name is
ems_ha_smallconfig_primary_2.vmdk. Click OK after selecting the file.
Figure 278: Select virtual disk suffixed with _2
37. Click Next.

38. Choose SCSI (1:1) for the Virtual Device Node option.

Figure 280: SCSI 1:1 selection with Independent and Persistent options
40. Click Finish.

Figure 281: Second Virtual Disk Completion

Figure 282: Click OK to complete Disk completion
Follow instructions to upload the EMS ISO image to the SAN datastore. Then mount the iso as per
the steps specified and start the VM to initiate the EMS installation.
Downloading EMS HA SWe Software Package from Salesforce
The EMS HA SWe application is available as a software package downloadable from the SalesForce Customer
Portal.
1. Log on to Salesforce customer portal using your Sonus provided login, and click SOFTWARE DOWNLOADS
.
3. Fill in the Software Download Form, accept the license agreement, and click Submit.
5. Download EMS ISO image emsrac-V09.03.00R000-RHEL-06.04.02.00R000-x86_64 to your local
Uploading EMS SWe HA Software Image to Datastore
This section describes the steps to upload the EMS ISO image from your system to the SAN datastore. After
downloading the EMS ISO package from SalesForce, you need to upload the ISO file to the SAN datastore. After

the ISO image is available on SAN, it can be used to install EMS on VMs.
Ensure you have downloaded the EMS ISO file from SalesForce, to your system, before executing the
following steps. For details on how to download ISO from SalesForce, refer the section Downloading EMS
HA SWe Software Package from Salesforce.
To upload the EMS Software ISO image to SAN datastore, perform the following steps:
1. In the main vSphere client window, select the VM from the left pane.
2. Click the Summary tab on the right pane, and right-click on the SAN datastore name; select Browse
Datastore... from the drop-down menu.
3. In the Datastore Browser window, click Upload files to this datastore.

4. Select Upload File... option.
5. Select the ISO from your system where it was downloaded from SalesForce. Click Open to upload it to the
SAN Datastore.

6. The Uploading... window pops up and shows the status of upload. Wait for the ISO to get uploaded on to the
SAN datastore.
Mounting HA ISO Image on VMware
The following steps describe how to mount the EMS iso image on a VM you have created:
1. Select the VM from the left and choose Edit Settings.

2. Select the CD/DVD drive 1 option and select the Connect at power on check box. Click the Datastore ISO
File option and click the Browse... button.

3. In the Browse Datastores window, select SAN datastore.

4. Select the EMS iso file uploaded earlier.
5. Click OK to close the Browse Datastores window.

To perform an EMS SWe installation on VMware for HA, first perform the EMS HA iso installation on both the HA
nodes separately. The EMS HA iso installation, performs lLinux installation and EMS installation. After that you need
to perform the EMS HA application installation and set-up the HA configuration for active and secondary system to
work as a HA pair.
This section includes the following topics:
Performing EMS HA iso Installation on VMware

Performing EMS HA iso Installation on VMware
To perform the installation of EMS Software Application on VMware for a HA setup, perform the following steps first
on the primary EMS VM followed by secondary EMS VM.
1. Ensure that both the Virtual Machines on primary and secondary systems are started, before performing
installation.
If the VM is not started, you need to start the VM.
a. To start the VM, right click on the newly created VM and click the Open option:

a.
Figure 292: Opening a VM
2. Type 1 and press ENTER to start the EMSRAC Installation.
This starts the installation of the Linux OS packages.
The following screen appears after some time, indicating the percentage of the Linux packages installed.

up to 30 minutes.

3. After successful installation of Red Hat Enterprise Linux, the reboot screen is displayed. Use the Tab key to
select the Reboot button. After selecting the Reboot button, press the Space key to reboot the system.

4. To release the VM locks on the mounted ISO, perform the following steps:
a. Right-click on the machine-name and select Edit Settings from the menu.
b. Select CD/DVD drive 1 (edited) and clear the Connect at power on check box.

c. A confirmation message is displayed as shown in the following figure. Click Yes and click OK, to
disconnect the ISO.
Figure 298: Confirmation message
d. Go back to the Reboot screen and press the Enter key.

5. After reboot, the Sonus Network Configuration screen is displayed.
6. Select Hostname and press the Space key configure the host name for the system.

6.
a. In the Host Configuration Screen, specify the Hostname, Primary DNS, and DNS Search Path details.
Press the Tab key to select the OK button and press the Space key to save the settings.
Primary DNS Server IP Address, Secondary DNS Server IP Address and DNS Search Path
are optional.

Figure 300: Hostname
b. Use the arrow keys to select IP Configuration and press the Space key to configure IP address.
Select eth0 interface for which you need to configure the IP Address. Use the Tab key to select the
OK button and press the Space key to configure IP address for eth0 network interface.

key to move the cursor to other parameter. Press the Tab key to select OK and press the Space key
to save IP Address details.

d. Use the arrow keys to select Time Zone and press the Space key to configure the time zone. Select
the nearest time zone for the system and press the Tab key to select OK and press Space to save the
time zone settings.

7. Enter NTP Time Server IP Address, to synchronize the time for the VM host system and click OK.
Figure 304: NTP Server IP Address
8.

The log in screen appears:

b. Same letters
f. Dictionary words

The above procedure completes the RHEL 6.4 OS and ISO installation on primary EMS HA system. Similarly,
you need to perform the RHEL 6.4 OS and ISO installation on secondary EMS HA system.
EMS HA VM installation procedure is similar to EMS HA physical (HP G8) based installation. Only difference is in
some configuration parameters used for installation (for example _public_interface is eth0 for VM, instead of
bond0).
EMS installation script (RACinstall_1) requires a configuration file. Create the configuration file by copying it from
a template file available under /export/home/pkg and then manually setting values for relevant fields. Use this
configuration file as input to installation script.
Perform the following procedure to configure the values for the template configuration files:

3. Copy template configuration file to /tmp and rename it:
# cp rac.conf_VM.template /tmp/vm.rac.conf
# chmod +w /tmp/vm.rac.conf
4. Edit the vm.rac.conf template file.

4.
For private IP, do not use the same private IP of the hypervisor.
# vi /tmp/vm.rac.conf

_ntpServer=
from)
_node01=

_node02=

_node01_public_ip=

_node02_public_ip=

_node01_public_vip=

_node02_public_vip=

_clusterName=
sonusVIP.IPv4=

ipv6Support=false



sonusVIP.IPv6=




_array_controllerA_IP=
_array_controllerB_IP=
# Public interface name, leave at default value

_public_interface=eth0
# Private interface name, leave at default value

_private_interface=eth1

# Storage RAID type, not required for VM
_storage_type=
After updating the values, press the ESC key and enter :wq! to save the configuration.
The following section provides details about running the EMS Installation scripts:
This section covers following topics:
RACinstall_1 script
RACinstall_1 script
This script performs initial RAID and network related configuration across both nodes.
1. Navigate to the path /export/home/pkg, using the following command:
[root@emshp5vm1]# cd /export/home/pkg
2. Run the following command on the primary HA node:
[root@emshp5vm1 pkg]#./RACinstall_1 /tmp/vm.rac.conf

...
Generating and installing cluster-specific ssh keys for oracle .......... (ok)
3. After the script is successfully executed, you can proceed to the next step, which is EMSRACinstall script.
Perform the following procedure to create EMS partitions, install Oracle Clusterware and Oracle RAC on the primary
server.
all/logs.

1.
# ./EMSRACinstall
Checking dependencies ................................................... (ok)

Starting EMS installation on emshp5 ..................................... (ok)
Performing a FRESH installation of Insight EMS .......................... (ok)
...Command output cut for brevity...

Completed EMS installation on emshp5 .................................... (ok)
The Insight EMS HA installation for VMware is complete.
primary node at /var/sadm/install/logs. If there are errors during the installation, refer to RACinsta
ll_1.<id>.log and RACinstall_2.<id>.log and EMSinstall.<id>.log .The DB installation log
files are located at /opt/oracle/orasql/SIDB01 on the primary node.
Based on your requirements, obtain the required license from Sonus and install the licenses using License
Manager. For more information about how to install Licenses, refer the License Manger section in EMS
User Guide.
EMS SWe DR Configuration for EMS VMware

Overview
Disaster Recovery setup consists of a source site and target site, both deployed at a geographical different
locations. In case, if the source (primary database) Insight system is disabled, the target system (standby database)
can be switched to the production role, thus minimizing the downtime and data loss associated with the outage. The
EMS Software Version V09.03.00 installed virtually on VMware, supports Disaster Recovery (DR) setup for both
Standalone and High Availability (HA) systems.

CAUTION
The EMS Software-only V09.03.00 on VMware deployed for a DR setup, must have same deployment type
(Standalone or High Availability) on source site and target DR site.
Following combination of DR setups are not supported:
The EMS V09.03.00 on VMware does not support different source and target DR site
combination. For example, source site having an HA setup and target DR site deployed
with Standalone (SA) system.
Both the source and target DR sites must be installed on VMware. The DR setup does not
support software-only installation (VMware) on one site and physical server-based
installation on other DR site.
Installing EMS Software for DR Setup
Performing EMS Software-only installation virtually for a DR setup is same as installation of EMS Software on
VMware for Standalone and HA. There is one additional step to be performed for DR deployment. After installing
EMS Software on both the source and target DR site, execute the /opt/sonus/ems/conf/DR/manageDR setup
command on source DR site to (if EMS HA, run on primary node of source site) configure and synchronize the
source (primary DB) and target (standby DB) sites for replication.
The following table lists the high-level steps with corresponding links for installing EMS Software-only V09.03.00 on
VMware for a DR setup.
High-level Installation Steps using VMware for DR Setup
The high-level steps for installing EMS SA virtually on VMware for DR setup are listed in the following table.

Table 54: Installing EMS Software on VMware for a DR Setup
Step Task Task to be performed on Installing EMS Installing EMS High

Number DR Site (Source or Standalone Server Availability Server on
Target) on VMware VMware
1 Identify Installation Source and Target DR Installation Installation Requirements

Requirements Sites Requirements for for HA
Standalone (SA)
2 Download Files from Source and Target DR Downloading Files Downloading Files from
Salesforce Sites from SF SF
3 Creating VMware Virtual Source and Target DR Creating VMware Creating VMware Virtual
Machines Sites Virtual Machines Machines
4 Uploading EMS SWe SA Source and Target DR Uploading Image to Uploading Image to
Software Image to Sites Datastore Datastore
Datastore
5 Mounting ISO Image Source and Target DR Mounting ISO Image Mounting ISO Image
Sites
5 Perform EMS Installation Source and Target DR Performing EMS SA Performing EMS HA iso
Sites ISO Installation Installation
6 Install EMS HA Application Source and Target DR N/A Installing EMS HA

Sites application
7 Setup DR Source DR Site ONLY Setup Setup
8 Post-Installation Tasks Source and Target DR Performing Performing

Sites post-installation tasks post-installation tasks
For more information about DR Operations, refer EMS DR Operations.
Upgrading Insight EMS SWe on VMware ESXi
This section provides information on upgrading Insight EMS SWe on VMware ESXi.
procedure is to support the upgrade of EMS on VMware from 9.3.0 to EMS Releases above 9.3.0 release.
Upgrading EMS SWe Standalone on VMware ESXi

Upgrading EMS SWe HA on VMware ESXi
Upgrading EMS SWe DR on VMware ESXi
Upgrading EMS SWe Standalone on VMware ESXi

EMS SWe INPLACE Upgrade on VMware ESXi

EMS SWe Kickstart Upgrade on VMware ESXi

This section provides information for upgrading EMS SWe Standalone (SA) on VMware ESXi using an INPLACE
upgrade or Kickstart upgrade.
ID/trace
Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700
EMS SWe INPLACE Upgrade on VMware ESXi
upgrade.
Backup the EMS.
EMS SWe Kickstart Upgrade on VMware ESXi
The following summary outlines the key steps required to upgrade EMS standalone server using Kickstart upgrade.
Backup the EMS.

Performing KICKSTART Upgrade Procedure for EMS SA
Execute the following steps to perform a kickstart upgrade for EMS SA:
ID/trace
Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700

command:

file]


#


_ems_backup=

required.



remote server.

_backup_remote_IP=



on kickstarting the system, see EMS SWe Kickstart.
# rpm -qa SONSems

SONSems-V09.03.00-R000.x86_64

EMS SWe Kickstart
This procedure is used when kickstart upgrade fails, and you want to perform kickstart installation on VMware. The
VMware virtual machine would already have been created earlier because this is a re-installation.
The EMS SWe application is available as a software package downloadable from the SalesForce customer portal.
5. Download the EMS ISO image ems-V09.03.00R000-RHEL-06.04.02.00R000-x86_64 to your local
EMS SWe Kickstart procedure
Perform the following steps to kickstart EMS SWe on an already created Virtual Machine:
1. Login as root on the VMware host using the VMware vSphere client.
a. Enter VMware host machine IP Address.
b. Enter the root password.

Figure 307: VMWare VSphere Client Login
The vSphere Client main window appears.

2. Upload the EMS SA SWe Software Image to Datastore, by performing following steps:
a. In the main vSphere client window, select the VM from the left pane.
b. Choose the Summary tab on the right pane, and right-click on the SAN datastore name, select
Browse Datastore... from the drop-down menu.

c. In the Datastore Browser window, click Upload files to this datastore.
d. Select the Upload File... option.

e. Select the ISO from your system where it was downloaded from SalesForce. Click Open to upload it to
the SAN Datastore.
A warning is displayed, indicating if the same file-name exists on the target, it will be replaced.

Figure 312: Upload/Dowload Operation Warning
The Uploading... window pops up and shows the status of upload. Wait for the ISO to get uploaded on
SAN datastore.
Figure 313: Upload Progress Window
After the ISO is uploaded successfully, the following figure is displayed.
Figure 314: ISO Uploaded Successfully
3. Mount the EMS ISO image on VMware, by performing following steps:

a. Select the VM from the left and choose Edit Settings.

3.
a.
b. Select the CD/DVD drive 1 option and select the Connect at power on check box. Click the
Datastore ISO file option and click the Browse button.

c. In the Browse Datastores window, select SAN datastore.

d. Select the EMS iso file uploaded earlier.

e. Click OK to close the Browse Datastores window.

f. Click OK to close the Virtual Machine Properties window.

4. After the ISO Image is uploaded and mounted on VMware, install EMS SA on VMware, by performing the
following steps:
a. To start the VM, click Power on the virtual machine highlighted in the following figure:

Figure 320: Power-on Virtual Machine
b. After VM is powered-on, right-click on the machine-name and select Open Console.
Figure 321: Open Console
c. After the VM is started, the EMS Installation Option screen is displayed. Enter 1, to proceed with EMS
Installation.
To perform Insight Application Server (IAS) installation, enter 2 and proceed with IAS
installation.

To toggle between the console and other screens, press the CTRL+ALT keys together.
Figure 322: EMS Installation Options
The RHEL Operating System installation is performed on the VM as shown in the following figure.

Figure 323: RHEL Installation
After the RHEL OS is installed, post-installation checks are performed as displayed in the following
figure.

Figure 324: Post-Installation Checks
After RHEL is installed successfully and post-installation checks are successfully performed, the
Reboot screen is displayed.

Figure 325: Reboot
d. To release the VM locks on the mounted ISO, perform the following steps:
i. Right-click on the machine-name and select Edit Settings from the menu.
ii. Select CD/DVD drive 1 (edited) and clear the Connect at power on check box.
iii. A confirmation message is displayed as shown in the following figure. Click Yes and click OK,
to disconnect the ISO.

iii.
Figure 327: Disconnect CD-ROM Confirmation message
iv. Go back to the Reboot screen and press the Enter key.
After reboot, the Sonus Network Configuration screen is displayed.
e. Press Enter to configure Hostname.
f. Specify a relevant Hostname using which you can easily identify the VM host and click OK.
Primary DNS Server IP Address, Secondary DNS Server IP Address and DNS Search Path
are optional.

g. After configuring host name, Sonus Network Configuration screen is displayed. Select IP
Configuration using the arrow keys and press Space.

Figure 330: IP Configuration
h. Select the IP format (IPv4/IPv6) by which you want to configure IP address for eth0. Click OK.
Figure 331: IP Format (IPv4/IPv6)
i.

i. Enter the IP Address,Subnet Mask, and Gateway details for the virtual interface.
j. From the Sonus Network Configuration screen, select the Time Zone using the arrow-keys and
press the Space key to configure time zone.
i. Select the Time Zone where the VM host system is located from the list of time zones.

k. After configuring Time Zone, Sonus Network Configuration screen is displayed. Select Time Server

Figure 334: Timeserver
l. Enter the NTP Time-Server IP Address, to synchronize the time for the VM host system and click OK.
Figure 335: NTP TimeServer Configuration Screen
m.

m. Login screen is displayed, after the EMS Application Software Suite and Oracle database are
successfully installed on the VM Host. Login as root user and default password 'sonus' to the EMS
Software on the VM host system.
n. The first time you login as root user, after EMS installation, you are enforced to change the default
password 'sonus'. Specify the current password and the New password that you want to set.
Ensure that new password is not a dictionary word or too similar to the current password.

After successfully installing EMS, the following screen is displayed.

Figure 338: EMS Installation Completion
This completes the EMS Installation on VMware virtual machine.
After completing the EMS Installation, perform the mandatory post-installation tasks. For
more details about post-installation tasks, refer the section Performing Post-Installation
Tasks.
Based on your requirements, obtain the required license from Sonus and install the licenses
using License Manager. For more information about how to install Licenses, refer the Licens
e Manger section in EMS User Guide.
1. Install Insight EMS by performing the following:
a. Perform Insight Installation using old ISO. For more information, see " EMS SWe Kickstart".
b. Perform " Performing EMS Post-Installation Tasks".
$ ./sonusEms start
2.



log

Upgrading EMS SWe HA on VMware ESXi

Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700
for upgrade.

a. Perform EMS Installation using the old ISO. For more information, see " Kickstart the HP G8 Servers".
b. Installing EMS HA Application and Configuring HA .

exp_data_manual.dmp


log

Upgrading EMS SWe DR on VMware ESXi

This section provides information on upgrading EMS SWe Standalone (SA) and HA for DR configuration on VMware
ESXi.
Upgrading EMS SWe SA for DR Configuraton on VMware ESXi Upgrading EMS SWe HA for DR
Configuraton on VMware ESXi
Upgrading EMS SWe SA for DR Configuraton on VMware ESXi
configuration.
Backup the EMS.

source EMS system.
EMS system.

Upgrading EMS SWe HA for DR Configuraton on VMware ESXi
Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700

Common Administrative Tasks for EMS VMware
EMS SA Administrative Tasks
For EMS SA administrative tasks, refer the section Insight Server Administration.
EMS HA Administrative Tasks
For EMS HA administrative tasks, refer the section EMS Server Administration for HA Linux.
EMS Database Tasks
For EMS database tasks, refer the section Insight Server Database Administration.
Deleting EMS SA VMs
This procedure describes the steps for deleting the SA VMs. This section is only applicable, when you do not want
to use the VMs anymore. You would not normally need to perform this procedure.
Deleting the SA VMs, results in data loss on the disk.
Perform the following steps, to delete the SA VM:
1. Shutdown the SA VM, if running.

2. Select the VM from the vSphere client window left pane and right-click and select the Delete from Disk
option.
3. Choose Yes for the delete confirmation popup message. This completes the SA VM deletion procedure.
Deleting EMS HA VMs
This procedure describes the steps of deleting the HA VMs. This section is only applicable, when you do not want
to use the VMs anymore. You would not normally need to perform this procedure.
Deleting the HA VMs, results in data loss on disks of both the VMs.
Perform the following steps, to delete the HA VMs:
1. Shutdown both (on primary and secondary hosts) the VMs if running.
2. First delete the VM on secondary host by following the steps below.
a. Select the VM from the vSphere client window left pane and right-click and select the Delete from
Disk option.
b. Choose Yes for the delete confirmation popup message.
3.

3. Delete the VM on the primary host, by following the step 2 performed earlier. This completes the HA VM
deletion procedure.

Insight IAS is supported on VMware or KVM virtual machine in both small and large configuration options. Host
hardware requirements and disk space requirements for IAS on VMware or KVM with small and large configuration,
are the same as those for EMS Standalone on VM.
The following summary outlines the key steps required to install IAS SWe application on KVM or VMware.
Ensure that prerequisites for hardware and software requirements are met.
This step lists the hardware and software prerequisites for KVM or VMware.
Link to Hardware and Software requirements for KVM
Link to Hardware and Software requirements for VMware
Create the VM (either KVM or VMware) and Kickstart the VM
This step creates the Virtual Machine (VM) instance for installing IAS, kickstarting the VM with IAS iso image.
Enter option 2 to install IAS base image.
Link to VM creation and installing IAS for KVM
Link to VM creation and installing IAS for VMware
Run the remoteIasMgmt.sh script from EMS
Run the remoteIasMgmt.sh script from Insight EMS VM to install the IAS software load on the newly created
IAS VM.
Link to IAS Remote Installation Procedure
IAS Remote Installation Procedure

Perform the following procedure to install the IAS software:
This procedure is not applicable to install IAS remotely from Linux to Solaris IAS.
# sh remoteIasInstall.sh <ias_ip_address>
where <ias_ip_address> is the IP address of the remote system on which you want to install IAS.
Messages appear that state that remote information is being retrieved and installation files are being copied
to the remote system. When the IAS is ready to be installed, a message appears that this may take several
minutes.

started.

$ ./remoteIasMgmt.sh start <ias_ip_address>
where <ias_ip_address> is the IP Address of the IAS, which can either be an IPv4 or an IPv6 address type. The
# ./remoteIasMgmt.sh stop <ias_ip_address>
where <ias_ip_address> is the IP Address of the IAS. The script prompts you for the root or insight user

Setting the IP Address and System Password of EMS SA VM

Installing the PSX Manager GUI on EMS
Changing IP Address on KVM and VMware based EMS SWe
For password related information, refer the section Managing Insight Account Names and Passwords".
In addition, the following post-installation tasks (mandatory/optional) must be performed depending on your
requirement.
For more information about post-installation tasks, refer the page Performing Post-Installation or Upgrade Tasks.

Setting the IP Address and System Password of EMS SA VM
The configuration involves setting IP address and changing the passwords.
You can configure the EMS system IP address and passwords using the configureJumpstart.sh script. The
configureJumpstart.sh script changes the server IP address and updates this IP address in the database
tables. Also, this script updates the Netcool license information with the IP address.
For more information about password, see Password Complexity.
Perform the following procedure to set the IP address and the system passwords:
1. Log in as root.
# ./configureJumpstart.sh
3. Enter the EMS IP address of the system, when prompted.
You can use the EMS IP address that you have configured while performing the EMS ISO
installation. Else if you want to change the EMS IP address, you can enter a new IP address.
4. If the following message appears, enter Y if you want to continue and overwrite the existing key.
A key file already exists.

Do you want to continue and overwrite the existing key [y|Y,n|N] ? y
The following messages appear:
Generating a new Key file...
Do you want to upgrade the system passwords to use strong passwords

(production setup) (y|Y) or continue to use the old weak hardcoded passwords
(lab setup) (n|N) (default:Y)?
If you want to use strong passwords (recommended for production setup), enter Y and skip to Step 6.
You can enter new passwords.
If you do not want to use strong passwords, enter N and continue to Step 5. The default passwords

can be used.
When a message appears stating that the script is done, continue to 'Post-Installation Steps'.
When entering strong passwords (Steps 6 through 18), the passwords must meet the restrictions me
ntioned in Password Complexity.
6. If you entered Y in Step 4, a prompt asks for the EMS database (dbimpl) password. Enter the password. (The
only special characters allowed are _, $, and #.).
7. When prompted, re-enter the EMS database password.
8. When prompted, enter the EMS database sys password. (The only special characters allowed are _, $, and
#.)
9. When prompted, re-enter the EMS database sys password.
10. When prompted, enter the EMS database system password. (The only special characters allowed are _, $,
and #.)
11. When prompted, re-enter the EMS database system password.
12. When prompted, enter the EMS user password. For high availability and disaster recovery systems, you must
use the same EMS user password on each EMS system.
13. When prompted, re-enter the EMS user password.
18. When a message appears stating that the script is done, continue to 'Post-Installation Steps'.
Installing the PSX Manager GUI on EMS

This section provides information on installing the PSX Manager GUI on EMS:
Installing the PSX Manager GUI on EMS Standalone (SA) VM

Installing the PSX Manager GUI on EMS High-Availability (HA) VM
The installation of PSX Manager GUI on EMS Server is only necessary if the PSX Manager Version is later
than the PSX Released version shipped with the EMS release. The following procedure is optional and
need not be performed, if you are already using the PSX Manager GUI which has the same version as the
PSX release shipped with EMS release.
Installing the PSX Manager GUI on EMS Standalone (SA) VM

wards.

PSX V09.03.00R000
# su - insight
$ ./sonusEms stop
system.
# ./GuiClient.sh

SONSems-V09.03.00-R000.x86_64
SONSpsx-V09.02.00-R000.x86_64

Removing SONSpsx.
Installing SONSpsx.
Preparing... ########################################### [100%]
1:SONSpsx ########################################### [100%]

PSX V09.03.00R000
# su - insight
$ ./sonusEms start

Installing the PSX Manager GUI on EMS High-Availability (HA) VM

wards.

PSX V09.03.00R000

server:
# su - insight

system.
# ./GuiClient.sh

SONSems-V09.03.00-R000.x86_64
SONSpsx-V09.02.00-R000.x86_64

Removing SONSpsx.
Installing SONSpsx.
Preparing... ########################################### [100%]
1:SONSpsx ########################################### [100%]

PSX V09.03.00R000

16. Start EMS on the primary and secondary server as user insight, by executing the following command:
# su - insight
Changing IP Address on KVM and VMware based EMS SWe
This section provides information for changing IP address of EMS SWe on KVM or VMware.
This procedure is optional and should be performed, only if you want to change the IP Address of hosts on
which KVM and VMware based EMS SWe VMs are hosted.
Perform following steps to change the IP address of host on which KVM or VMware based EMS SWe is hosted:
2.

3. Have your UNIX/Linux System Administrator change the address of the system. If you also want to change
the hostname of your system, have your UNIX/Linux System Administrator change it at this time.
4. As root user, change the IP address of the server, change the IP address in the database tables, and
update the Netcool license information as follows:



c/hosts
6. Start Insight.

Insight EMS Solaris Upgrade
This section provides information on Upgrading EMS for Solaris platform.
Table of Contents

The Insight Element Management System (EMS) Software Upgrade for Standalone (Solaris) provides detailed
instructions about upgrading the Insight EMS software package and other software packages required for its
operation.
Table of Contents

Introduction to EMS Standalone
Upgrading the Insight Application Server
Introduction to EMS Standalone Upgrade
Upgrading Insight Standalone Using Sonus Salesforce (Solaris)
Managing Insight Account Names and Passwords-SA Solaris
Configuring IPv6 on SA Solaris
Common Administrative Tasks-SA Solaris
Performing Post-Upgrade Tasks on SA Solaris
ILOM Configuration on the Netra T5220
Migrating Insight Standalone 240 or 440 System to a Netra T5220
Managing Security Settings of Insight SA on Solaris Platform
Introduction to EMS Standalone
This section provides an overview of Insight Element Management System (EMS) and provides information about
hardware requirements.
Overview on EMS

Figure 339: Sonus EMS
Hardware and Software Configuration for EMS Standalone
The following section details the hardware and software configuration for Insight EMS Standalone.
Many factors, from network topology to the nature of user operations, affect the performance of the system. The
Insight application is memory- and I/O-intensive, particularly when performing large data collections and exporting. If
you do not collect performance data extensively or frequently, then the platform's ability to support managed devices
and users increases. Under heavier loads the performance of the system will degrade gracefully.
Hardware Configuration
The following tables lists the hardware configurations required for Insight EMS Standalone system.
Table 57: Current Netra T5220 Hardware Configurations Available from Sonus.
Sun Netra Platform Configuration
Netra T5220 (four-drive) 4 x 1.2 GHz CPU, 16 GB memory, 4 x 146 GB hard drives, 4 x 10/100/1000 Ethernet Ports.
Netra T5220 Disk Partitioning

The following table details the Sonus recommended disk partitioning scheme for the Netra T5220.
Table 58: Recommended Netra T5220 Disk Partitioning (first disk).
Partition Name Partition Size
root (/) 5GB
var (/) 4GB
opt (/) 5GB
HOME (/export/home) remaining space not used by other partitions
/export/home/oracle/oradata 50GB
SWAP (/swap) 16GB
(reserved) 0.15GB
Table 59: Recommended Netra T5220 Disk Partitioning (second disk).
Partition Name Partition Size - 146GB Disk
HOME (/export/home2) remaining space not used by other partitions
/export/home/ems/weblogic/sonusEms/data 60GB
(reserved) 0.15GB
Disk Mirroring
Software disk mirroring for Insight is supported on Netra T5220 four-disk systems. The following mirrors are set up:
Disk 1 <-> Disk 3

Disk 2 <-> Disk 4
In addition to protecting against disk failure, enabling disk mirroring will also make it easier for you to perform a
fallback to Insight V09.03.00 from future Insight upgrades, particularly HA upgrades.
Java Insight and Database Software Memory Settings
The main Java Insight memory settings and database software memory settings are automatically recalculated on
upgrades or system reboots. If changes to the automatically calculated settings are needed, contact the Sonus TAC.
UPS Recommendations
Sonus recommends that the Insight platform be protected by an uninterrupted power supply (UPS) to prevent the
ungraceful shutdown of Netcool. An ungraceful shutdown of Netcool can cause database file corruption that

prevents the nco_objserv process from coming up.
This section lists the Insight software platform requirements:
Table 60: Insight Software Platform Requirements.
Solaris 10 Sonus-hardened Solaris 10.0
OS Patch Version Generic_150400-20
Sun Integrated Lights-Out- System Firmware version is 7.4.7

Management (ILOM)
Sun Netra SNMP Management Agent Sun Netra SNMP Management Agent 1.6.2
Lsof 4.8
Sun Cluster 3.2U2
Sun Cluster Agent for Oracle 3.2U2
Oracle Software Version 11.2.0.3 (Srs)
Appware version 07.77.20.00, 07.83.27.00
Bootware version 07.77.20.00, 07.83.27.00
Java Server version 1.7.0_72
Java Client version 1.7.0_72, 1.8.0_45 (*)
plugin.
Upgrading the Insight Application Server
The Insight Application Server (IAS) lets you run the Insight API, the Insight SMS API, the SGX API, and the Lawful
Intercept Target Provisioning API on a system other than the Insight server. For an overview of the IAS, see Insight
Application Server.
You require two servers to install Insight and IAS. You need to install Insight on server A before installing IAS on
server B.

After Insight is upgraded, Sonus recommends that each IAS be upgraded as soon as possible to ensure
consistent operation with the EMS. Older versions of IASs cannot run new versions of the API or handle
new features. While an IAS is being updated, any API clients or HTTP load balancer should be configured
to direct requests to Insight or other IASs.
Before You Begin
Before you begin the IAS upgrade, you must:
Know the IP address of the remote system on which you want to upgrade IAS
Know the password for the root user on the remote system
Have a system that meets the specifications in Hardware and Software Configuration for EMS Standalone.
Sonus recommends that you start Insight on the EMS before you upgrade the IAS
This section includes the following sections:
Table of Contents
Upgrading an IAS
Other IAS Procedures
Upgrading an IAS
To upgrade an IAS perform the following tasks:
Determining the Solaris Patch

To determine whether the Solaris patch has already been installed on your system, perform the following steps:
1. At the command prompt, enter:
uname -v
2. Read the output. If the following line appears, the Solaris patch has already been installed:
Generic_150400-20
If the output does not match the previous message, install the Solaris OS patch. For more details, see Step 1
Upgrading Solaris Operating System.

# cd /export/home/ems/conf/IAS
the remote system.
started.
$ cd /export/home/ems/conf/IAS
where <client_ip_address> is the IP Address of the IAS, which can either be an IPv4 or an IPv6 address type. The
where <client_ip_address> is the IP Address of the IAS. The script prompts you for the root or insight user password
of the IAS system and then proceed with the command.
Other IAS Procedures

This section provides the following additional IAS procedures:

Updating the Insight IPv4/IPv6 Address on the IAS
Updating the Insight IPv4/IPv6 Address on a Specific IAS
Updating the Insight IPv4/IPv6 Address on All IASs
Changing the Hostname and/or IPv4/IPv6 Address of the IAS
Licenses for Enabling Insight API, SMS API, SGX API, and Lawful Intercept Target Provisioning API on the
IAS
To obtain the status of an IAS server, Log on to the Insight EMS server as either root or insight and do the following:
of the IAS system and then proceeds with the command. The output of the status command looks similar to the
following:
Retrieving version information from the xxx.xxx.xxx.xxx.

The version information for xxx.xxx.xxx.xxx:
Curr IAS version: V09.03.00R000
Prev IAS version:
Curr Agent version: V09.03.00R000
Prev Agent version:
Curr JBoss version: 5.1.0
Prev JBoss version:
Curr JRE version: 1.7.0_13
Prev JRE version:
Curr Axis version: 1.1
The IAS server on xxx.xxx.xxx.xxx is running.
To update the Insight IPv4/IPv6 address on a specific IAS, perform the following:
As root on the Insight server, enter the following commands:

IPv4/IPv6 address.
following:
On the Insight server, enter the following commands:
The Insight IPv4/IPv6 address on all IASs that are registered to the Insight server are updated to the IPv4/IPv6
address of the Insight server.
change any additional files. You do need to:
Update the IAS node in the Insight Node Registration Page, and rediscover the IAS node. See “Updating a
Node” in the Insight Administration chapter of the Insight EMS User Guide.
Licenses for Enabling Insight API, SMS API, SGX API, and Lawful Intercept Target
Provisioning API on the IAS
Perform the following procedure to enable HTTP access on IAS server.
1. To enable HTTP access on IAS server, execute the following command:

# cd <IAS_BASE>/bin
# ./enableHTTP.sh

[y,n] y
Stopping IAS...
IAS Server stopped.

Modifying /export/home/ias/server/deploy/jbossweb.sar/server.xml
To disable HTTP access on IAS server, execute the following command :
# cd <IAS_BASE>/bin
# ./disableHTTP.shDisabling HTTP access to IAS server
The IAS server will be stopped now. Do you want to proceed? (default: yes) [y,n] y
Stopping IAS...
IAS Server stopped.

Introduction to EMS Standalone Upgrade
Table of Contents
Insight SA Upgrade Considerations
This section provides an introduction to the upgrade framework, upgrade paths, and upgrade scenarios before
describing the Insight Software upgrade procedures.

Insight Upgrade Framework
Pre Upgrade Phase (preInstall.pl)
Main Phase (mainInstall.pl)
Post Phase (postInstall.pl)
Insight Upgrade Paths
Upgrade scenarios
Insight Upgrade Files
Insight Upgrade Framework
You can upgrade Insight using the emsBootstrap-V09.03.00R000.tar file that you obtain from the Sonus
Salesforce Customer Portal. This tar file contains necessary files and scripts of the Insight upgrade framework. The
upgrade framework has divided the complete upgrade procedure into three major phases such as pre, main, and
post.
Pre Upgrade Phase (preInstall.pl)
Pre Upgrade phase validates the current state of the Insight system.
The preInstall.pl script displays relevant messages and guides the user through the upgrade procedure.
During this phase, all the configuration details are collected and the required database, fault management, and
configuration backups are taken before proceeding to the next phase of Insight upgrade.
The preInstall.pl script generates the Third party software, Operating System, and Firmware version details of
the current system and also the versions that are required to upgrade Insight to the targeted system.
Main Phase (mainInstall.pl)
Main Upgrade phase automates the upgrade process. It displays the current upgrade activities on the screen.
Post Phase (postInstall.pl)
Post Upgrade phase cleans up or removes the unnecessary data or files from the system.
Insight Upgrade Paths

For information on the Supported and other Supported (but not explicitly tested by Sonus) Insight Upgrade Paths,
refer the Insight Release Notes for Solaris.
The following table lists the different Insight software upgrade scenarios:
Upgrade scenarios
Scenario Description
Single Insight Server Upgrade You can upgrade an Insight standalone Insight software by using the Insight installation
from Sonus Salesforce Customer script and the Sonus Operating System patch from the Sonus Salesforce Customer
Portal Portal.
Insight Upgrade Files
The following files need to be downloaded from Sonus Salesforce Portal before you start the upgrade:

File Name Upgrade using FTP (Salesforce)
Sonus_OS_delta_9.3_Upgrade.tar.gz Mandatory
EMS_SonusDBPackage_solaris-V09.03.00R000.tar Mandatory
Solaris_Utilities_<current_release_name>.tar Mandatory
emsBootstrap-V09.03.00R000.tar Mandatory
EMS.V09.03.00R000.tar.Z Mandatory
SSGUI_V09.03.00R000.tar Optional
SONSdocV09.03.00R000.tar.Z Optional to view the Online documents
Insight SA Upgrade Considerations

The following are the Insight SA upgrade considerations.
Network Upgrade Sequence

Using IAS During Insight Upgrades
When an existing network is to be upgraded, use the following upgrade sequence for the network elements that will
be upgraded:
1. Obtain the required software licenses for additional software modules you will be adding. For more
information on Insight licenses, see Licenses for Enabling Insight API, Insight CLI, SMS API, SGX API,
Lawful Intercept Provisioning API, and Traffic Manager. You will apply the licenses in Step 9.
2. Upgrade the Insight Element Management System server software.
When upgrading a system that is running HPC, avoid loss of HPC service by installing and
activating the HPC license (NW-HPC) after you upgrade Insight and before you upgrade PSX. See
the Insight EMS User Guide for details.
3. Upgrade the DSI software.

4. Upgrade the PSX software. The PSX software is always compatible with the previous version and new
version of the GSX software.
For upgrading/downgrading PSX Manager independantlyof Insight, refer to the

“Upgrading/Downgrading PSX Manager Software” section of the PSX Installation and Upgrade
Guide (PSX Installation and Upgrade Guide).
5. Upgrade the SGX software.

6. Upgrade the GSX software.
7. Upgrade the ADS software.
8. Upgrade the ASX software.

8.
After you upgrade (or downgrade) software on a Sonus node (PSX, SGX, GSX, etc.), a user with
administrative privileges must rediscover the node in the Insight Administration page: in the Node
tab, select a node from the Sonus Managed Nodes list, and click the Discover button. Failure to
perform this rediscovery will result in the loss of Traffic Manager reporting and may result in
excessive error generation in the error logs (particularly in the case of a downgrade).
9. Apply the required licenses. For more information on Insight licenses, see Licenses for Enabling Insight API,
Insight CLI, SMS API, SGX API, Lawful Intercept Provisioning API, and Traffic Manager-SA Solaris .
This section addresses installation and/or upgrade of Insight only. For instructions on installing/upgrading
other network elements, consult the appropriate element guides.
Using IAS During Insight Upgrades
While an Insight server is being upgraded, EMS and SMS API requests from clients can be handled by IASs:
1. If you are not running HA, then you need to have at least two IASs to avoid a single point of failure. This is
because an IAS server cannot restart while Insight is down.
2. Before upgrading the Insight server, configure API clients or HTTP load balancers to direct API requests only
to IASs, not to the Insight server.
3. Upgrade the Insight server. While Insight is down, the IASs will continue to process EMS and SMS API
requests from clients.
4. After Insight is upgraded, Sonus recommends that each IAS be upgraded as soon as possible to ensure
consistent operation with the EMS. Older versions of IASs cannot run new versions of the API or handle new
features. While an IAS is being updated, any API clients or HTTP load balancer should be configured to direct
requests to Insight or other IASs.
Upgrading Insight Standalone Using Sonus Salesforce (Solaris)
Table of Contents
Prerequisites for SA Upgrade using Salesforce
Upgrade Procedure for Insight Standalone using Sonus Salesforce
Performing Post-Upgrade Tasks for Standalone Solaris
This section contains the instruction for upgrading Insight Standalone to Release V09.03.00 using the files from the
Sonus Salesforce Customer Portal.
Upgrade can take longer time if EMS releases (V07.03.07, V08.04.00R000 or versions higher) are directly
installed or upgraded to any other release. The upgrade time can be longer depending on the number of
rows in IPTRUNKGROUPINTERVALSTATS table. It is recommended to reorder the columns in this statistics
table in another maintenance window prior to upgrading EMS. For more information, contact Sonus
Customer Support.
Prerequisites for SA Upgrade using Salesforce

This section provides the prerequisites before planning an Insight upgrade.
General Prerequisites

Prerequisites for Upgrade
Downloading EMS Bootstrap File
Downloading Solaris OS Patch File
Downloading Solaris Firmware File
Downloading Solaris Utilities File
Verifying Security Patch and Downloading Oracle Database File
Downloading Application Software File
Verify or perform the following items prior to upgrading Insight:
server name, refer Changing Netcool DB Object Server Name for EMS SA.
You have read Insight Upgrade Considerations.
Download the latest version of EMS documents from the Sonus Salesforce Customer Portal.
You have super user (root) access on the Solaris system.
You should be aware of the Insight account and default passwords. For more details, see Insight Account
Names and Passwords .
You have terminal access to the server on which you are upgrading Insight.
Your system meets the minimum hardware requirements (Hardware Configuration).
(TAC).
Prerequisites for Upgrade
For Rollback using disk mirroring, you need to do the following setup:
1. If you experience any issues in your production network following an upgrade, you can return to the previous
version of Insight using disk mirroring.
Rollback using disk mirroring is supported only on Netra T5220 devices with 4 disks
a. The following mirrors are available where disks 0, 1 are master disks and 2,3 are slave disks.
Before upgrading, following mirrors are set up:
Disk 0 -> Disk 2
Disk 1 -> Disk 3
Refer section Enabling Disk Mirroring for enabling disk mirroring.
b. If you intend to use Disk mirroring as a rollback option, then make sure that mirroring is enabled, and
that the mirrors are in sync, using 'metastat -c' command.
This should be done before performing any upgrade related tasks.
Please note that using Disk mirroring as rollback option will require physical access to the
system, in case of upgrade failure, to swap the disks.
c.

c. After verifying that mirrors are in sync, detach the mirrors, so that mirroring no longer takes place.
Refer to Detaching Slave Disks from the Mirror.
Detaching disk mirroring enables you to recover original EMS installation in case of upgrade failure.
Download the following files from Sonus Salesforce Customer Portal to perform the Insight Upgrade.
Topics included in this section are:

Perform the following steps to download the EMS Bootstrap file: emsBootstrap-V09.03.00R000.tar
from Sonus Salesforce Customer Portal and place the file in the EMS server:
1. Login to a shell on the EMS Server as root user.

# mkdir -p /export/home/install/ems/
3. Download the emsBootstrap-V09.03.00R000.tar file from the Sonus Salesforce Customer Portal to
/export/home/install/ems/
4. Untar the emsBootstrap-V09.03.00R000.tar file by entering the following command:
# tar xf emsBootstrap-V09.03.00R000.tar
5. Ensure that all the extracted files have owner and root privileges by entering:
# ls -l
If not, change the owner and groups as follows;
# chown -R root:root *
The manual tar extraction should be done only in case of Solaris standalone EMS.

Here are the steps to download the Solaris Operating System file Sonus_OS_delta_9.3_Upgrade.tar.gz
For upgrading the Insight to V09.03.00, the Solaris Operating System patch version must be
Generic_150400-20.
1. Determine the Solaris patch level by entering the following command:
# uname -v
Read the output, if the following line appears, the Solaris OS patch has been already installed, and you can
skip the remaining steps.
Generic_150400-20
If the output does not match the message above, you need to install the Solaris OS patch.
2. Download the Sonus_OS_delta_9.3_Upgrade.tar.gz file from the Sonus Salesforce Customer Portal to
the /export/home on the target server.
3. Enter to the location /export/home.

4. Unarchive the Solaris OS patch file by executing the following command:
# gzip -dc /export/home/Sonus_OS_delta_9.3_Upgrade.tar.gz | tar xf -
Perform the following steps to download the Solaris Firmware files.
1. Log in as root and enter the following:
# cd /export/home/packages
2. Unzip the 147309-09.zip file:
# unzip 147309-09.zip
This places the sysfwdownload and the Sun_System_Firmware-7_4_7-Netra_T5220.pkg files in the

/export/home/packages/147309-09 directory. The 147309-09.zip file is also available from the
Sonus Salesforce Customer Portal at WL9.3.

The Solaris_Utilities_<current_release>.tar is needed while upgrading SNMP software.
1. Determine the SNMP Management agent Version by entering the following command:
# pkginfo -l SUNWmasf SUNWmasfr
The package versions are displayed
If the packages are not at least version 1.6.2, then proceed the remaining steps, otherwise no need upgrade
the SNMP software and skip the remaining steps.
2. Create a directory by entering the following command:
# mkdir -p /export/home/tmp
3. Download the Solaris_Utilities_<current_release_name>.tar from the Sonus Salesforce

Customer Portal to /export/home/tmp.
4. Change to the temporary directory by entering:
# cd /export/home/tmp
5. Extract files from the Solaris utilities tar file by entering:
# tar xvf Solaris_Utilities_<current_release_name>.tar
6. Change to the directory containing the extracted files by typing:
# cd UTILITIES_<current_release_name>
7. Unarchive the SONUS_SNMP_1_6_2.tar.gz file by entering the following command:

# gzip -dc SONUS_SNMP_1_6_2.tar.gz | tar xf -
Perform the following steps to verify the Oracle Database version and security patch. If the Database version or
security patch installed is not the latest, download the Oracle Database file
EMS_SonusDBPackage_solaris-V09.03.00R000.tar from Sonus Salesforce Customer Portal to the EMS
server:
For upgrading the Insight to V09.03.00, the Oracle Database version should be 11.2.0.3.0 with the latest
security patch 19271438. Even if the existing database version is 11.2.0.3.0, verify and ensure that you
upgrade to the latest security patch 19271438.
1. Determine the Oracle version:

a. Login as user oracle by entering the following command:
su - oracle
b. Enter the following command:
sqlplus -version
If the following line appears, the Oracle Database 11.2.0.3.0 is installed. Even if DB version is
11.2.0.3.0, verify if the latest security patch has been installed.
SQL*Plus: Release 11.2.0.3.0
If the output does not match the message above, you need to upgrade the Oracle Database.
2. Execute the following command to verify if the latest Security Patch Update (SPU) has been applied or not:
su - oracle
b. Enter the following command to verify the latest Security Patch Update (SPU) version is applied on the
system:
$ORACLE_HOME/OPatch/opatch lsinv | grep 19271438

If the following line appears, the required Oracle Security Patch has been already installed, and you
can skip the remaining steps.
Patch 19271438 : applied on Wed Oct 01 19:58:21 IST 2014
If the command output does not match the latest Security Patch Update (SPU) version 19271438 then
you need to upgrade the Oracle Database.

a. Download the EMS_SonusDBPackage_solaris-V09.03.00R000.tar file from the Sonus
Salesforce Customer Portal to/export/home/oracle
The EMS.V09.03.00R000.tar.Z file is needed while executing mainInstall.pl
1. Download the EMS.V09.03.00R000.tar.Z from the Sonus Salesforce Customer Portal to

2. Enter the following commands to extract the file:
# uncompress EMS.V09.03.00R000.tar.Z
# tar xvf EMS.V09.03.00R000.tar
Upgrade Procedure for Insight Standalone using Sonus Salesforce

This section contains the following instruction for upgrading a standalone Insight using the Sonus Salesforce:
Upgrade Procedure Summary

Running the preInstall.pl
Upgrading the Third Party Software
Running the mainInstall.pl
Upgrading PSX Manager GUI on Insight EMS Server
Post Upgrade Tasks
Rollback to Previous Version using Disk Mirroring

Before upgrading Insight, you need to take a backup of /etc/inet/ntp.conf and /etc/issue files.
You can restore this after completing the upgrade.
Perform the following procedure to upgrade Insight using Sonus Salesforce:

1. Running the preInstall.pl.
2. Upgrading the Third Party Software
3. Running the mainInstall.pl.
4. Running the postInstall.pl.
During the execution of the preinstall.pl script, several files and DB entries are backed-up in the
following directories:
/export/home/ems/weblogic/sonusEms/data/cli/scripts
/export/home/ems/weblogic/sonusEms/data/pm_archive : Performance CSV files
This can increase the upgrade duration. If need to reduce the upgrade time, contact Sonus TAC.
The Insight upgrade may fail if there is insufficient space in the following directories:
/export/home/ems
/var
/tmp
Contact Sonus TAC for troubleshooting this issue.
The following procedure lists how to run the preInstall script:
1. To produce a log of the upgrade, use the /usr/bin/script command to create a record of the terminal
session. This command creates a sub-shell where you run the installation. When it completes, type exit to
terminate the script command. As super user, enter the following command:
/usr/bin/script -a <Log_file_name>
Script started, file is <Log_file_name>
2. Run the following preinstall script:
perl preInstall.pl
The preInstall script collects the current configuration details of the machine. The following message
appears:
************************************************************
EMS preInstall.pl for target release version V09.03.00R000
** Run this script BEFORE upgrading current EMS system
** (Press ENTER to select default values shown in braces)
*******************************************************
Starting preInstall.pl execution on : Tuesday, August 2, 2011 10:05:06 AM EDT

3.
1: Upgrade through FTP

2: Upgrade through Jumpstart (HDD/DVD/USB)
Your choice:
Select 1 to upgrade Insight using Sonus Salesforce Customer Portal.

This machine will be used as HA or standalone

(1: HA, 2: Standalone)? (default:1):
Select 2 for Standalone.

5. The following message appears.
If the upgrade path from the installed to the current EMS version is not supported:
Upgrade from current version of EMS "XXXXXXX" to EMS release version "XXXXXX"
is not supported.
Please contact Sonus Customer Support for additional information on supported
Insight Upgrade Paths.
Do you want to proceed with the upgrade procedure (y/n/Y/N)? (default:N):
If the upgrade path is supported but not explicitly tested by Sonus.
Upgrade from current version of EMS "XXXXXXXX" to EMS release version

"XXXXXXX" is supported but not explicitly tested by Sonus. You may go ahead
with the upgrade procedure.
Do you want to proceed with the upgrade procedure (y/n/Y/N)? (default:Y):
Enter N, if you want to stop the upgrade procedure. Or Enter Y, if you want to continue the upgrade
procedure.
6. If you have pressed Y, the following message appears:

Running checkInstallation.pl...
Starting checkInstallation.pl execution on : Friday, October 14, 2011 6:22:49
AM EDT
Checking server boot mode...
Verified server boot mode.
Checking "SONSems" package installation...
Package "SONSems" is installed.
Checking user account "oracle"
.
.
.
.......................................................
The following anomalous settings/conditions were detected.
These do not necessarily mean that there is a problem but they might warrant
further investigation:
...................................................
.................................................
......................................................................................Complete
checkInstallation.pl execution on : Tuesday, July 12, 2011 9:38:20 AM
checkInstallation.pl has identified some potential issues.
Press ENTER to continue if you have already investigated these issues.
Press Ctrl + c, if you want to exit from the script. Or Press Enter to continue.
Do you want to take backup of EMS configuration and databases (y/n/Y/N)?

(default:Y)
Enter Y, if you want to take a backup of the EMS configuration and database. Or Enter N, if you do not want
to take a backup of the EMS configuration and database.
Skipping backup of EMS configuration and databases.
Sonus recommends you to take a backup of the system if you need to rollback to the current
version.
8. If you have selected Y in the above prompt, the following prompt appears:
(please note that this may take some time) (y/n/Y/N)? (default:Y):
Enter Y, if you want to import the Activity Logs, PM Stats and TrunkGroup Tables.
Or
Enter N, if you do not want to import the Activity Logs, PM Stats and TrunkGroup Tables.
9.

Do you want to take the backup of Performance CSV files (y/n/Y/N)? (default:N)
Enter Y, if you want to take a backup of the Performance CSV files.

Performance csv files location ?

(default:/export/home/ems/weblogic/sonusEms/data/pm_archive):
If you want to take a backup of the Performance CSV files from a different location, enter the location details.
Or
Enter N, if you do not want to take a backup of the Performance CSV files.
Skipping backup of Performance CSV files.
Running backupData.pl...
.
.........................................
Moving the files to /export/home/backup.
Backup of Performance CSV files complete.
backupData.pl is complete.
Execution of backupData.pl is completed.
Do you want to push backup files to remote host (y/n/Y/N)? (default:Y):
Enter Y, if you want to push the backup files to the remote host.
You will be prompted to enter the following details:
Remote sftp host name or IP
Username for sftp
Login Password
Directory on remote host
Or
Enter N, if you do not want to push the backup files to the remote location.

preInstall is complete. Download the required tar file from Sonus SalesForce
Customer Portal and untar under current directory and run mainInstall.pl to
continue.
Completed preInstall.pl execution on : Tuesday, October 18, 2011 2:53:30 AM
EDT.
If the script indicates that you should upgrade the Operating System and Oracle, upgrade the same using "
Upgrading the Third Party Software".
If you have not installed or upgraded the latest Third Party Software versions on your system, then perform the
following:
Upgrade the Third Party software after preInstall.pl execution is complete.
The ILOM firmware upgrade procedure must be done before you perform Oracle upgrade and EMS
application upgrade.
Step 1 Upgrading Solaris Operating System

Step 2 Upgrading SNMP Management Agent
Step 3 Upgrading ILOM Firmware
Step 4 Upgrading the Database Software
Step 1: Upgrading Solaris Operating System
If you are upgrading to Insight V09.03.00, the Solaris Operating System patch version should be
Generic_150400-20. Installing the Solaris Patch may approximately take 90 minutes. Before upgrading the
Solaris Patch, you need to determine the Solaris Patch Level.
This section contains the following:

Determining the Solaris Patch Level
Upgrading the Solaris OS Patch
Perform the following procedure to determine the Solaris Patch Level:
# uname -v
The package versions are displayed.

2. Read the output. If the following line appears, the Solaris OS patch has already been installed:

Generic_150400-20
If the output does not match the previous message, install the Solaris OS patch.
You can copy the solaris OS patch from the Sonus SalesForce Customer Portal and then perform an upgrade.Copy
the Solaris OS patch Sonus_OS_delta_9.3_Upgrade.tar.gz from the Sonus Salesforce Customer Portal to a
location on the target server (example, /export/home).
Verify that the Sonus_OS_delta_9.3_Upgrade.tar.gz is available at /export/home. For details, see

Downloading Upgrade Files.
Perform the following procedure to upgrade the Solaris OS Patch Generic_150400-20:
1. Perform the following steps:

a. Log on as insight. (Command: su - insight).
b. Bring down the EMS by entering the following command:
$ /export/home/ems/sonusEms stop
Fault Management Data Server has been shut down.

Fault Management Core Services have been shut down.
Fault Management Sonus Services have been shut down.
......completed xslt transform
Done
Insight datasource synched
Remote exec server stopped
Sonus Insight has been stopped.
$ exit
c. Log on as oracle. (Command: su - oracle)

d. Issue the following commands:
$ sqlplus /nolog
SQL> conn / as sysdba
SQL> exit
$ exit

Do not use the /bin/csh or /bin/tcsh shells to install the Solaris patch cluster (the cluster will
not install correctly with those shells). Use one of the following shells: /bin/sh, /bin/bash, or
/bin/ksh.
Installation of patches should be performed using single user mode and should be performed
using terminal server port connection.
2. When the system prompt appears, issue the following command to reboot the system:
# reboot -- -s
3. Enter the root user password when the following prompt appears
Root password for system maintenance (control-d to bypass):
# mount /export/home
5. Perform the following steps to create the OS directory and extract the
Sonus_OS_delta_9.3_Upgrade.tar.gzfile.
a. Extract the downloaded Sonus_OS_delta_9.3_Upgrade.tar.gz file by using the following
commands:
# cd /export/home
# gunzip Sonus_OS_delta_9.3_Upgrade.tar.gz
# tar xf Sonus_OS_delta_9.3_Upgrade.tar
6. After the Sonus_OS_delta_9.3_Upgrade.tar.gz file is extracted, remove the tar file to free-up disk
space.
# rm -f Sonus_OS_delta_9.3_Upgrade.tar
7. Change to the directory containing the extracted cluster by entering:
# cd /export/home/Sonus_OS_delta_9.3_Upgrade
8. Upgrade the patches by entering:
# ./upgrade.sh
The script requires atleast 40% free space in /var partition.

If you encounter Return Codes 0, 1, 2, 4, or 8 during the patch installation process, you may ignore then.
# reboot -- -r
The output is displayed as follows before the system logs out to reboot:
Creating boot_archive for /var/run/.patch_root_loopbackmnt

updating /var/run/.patch_root_loopbackmnt/platform/sun4v/boot_archive
15+0 records in
15+0 records out
Then log on to the server after few minutes to verify the latest patch cluster.
10. To verify that the latest Solaris OS patch, enter:
# uname -v
The following message must appear:
Generic_150400-20
If Generic_150400-20 is not displayed, contact Sonus TAC.
11. Remove the OS package directory to reclaim space, by executing the following command:
# rm -rf /export/home/Sonus_OS_delta_9.3_Upgrade
Step 2: Upgrading SNMP Management Agent
If you are upgrading Insight using the Sonus Salesforce Customer Portal, you need to upgrade the SNMP
Management Agent to version 1.6.2.
1. Determining the SNMP Management Agent Version

2. Upgrading the SNMP Management Agent
Verify that the Solaris_Utilities_<current_release>.tar is available at /export/home/tmp. For

details, see Downloading Upgrade Files.
Determining the SNMP Management Agent version:

To determine the current version of the SNMP Management Agent, perform the following procedure:
1. As the root user, enter the appropriate command:

2. If the packages are not at least version 1.6.2, then perform Upgrading SNMP Management Agent.
Upgrading the SNMP Management Agent
Perform the following procedure to upgrade the SNMP Management Agent:
1. Login as root.
# cd export/home/tmp/UTILITIES_<current_release_name>/SNMP_1.6.2
3. Stop the SNMP agent that is running:
# /etc/init.d/masfd stop
4. Run the SNMP agent upgrade script. The script removes the old packages and installs the new packages.
# ./install.sh
5. Verify that the packages have been updated by entering the appropriate command. If the packages were
properly installed, the versions should be 1.6.2.
6. Start the SNMP agent by entering:
# /etc/init.d/masfd start
The changes on the SNMP daemon will take two minutes to start.
7. Confirm that the SNMP agent is running by entering:

7.
# ps -ef | fgrep snmpd
Step 3: Upgrading ILOM Firmware
If you are upgrading Insight using the Sonus Salesforce Customer Portal, you need to upgrade the ILOM firmware.
This section contains the following sections:
1. Determining the System Firmware Version

2. Upgrading System Firmware using CLI
Determining the System Firmware Version
To determine the current version of the system firmware, perform the following steps:
1. At the command prompt, enter the following:
prtdiag -v | grep "Sun System Firmware"
The Sun system firmware version is displayed, for example:
Sun System Firmware 7.4.7 2012/12/11 23:44
2. If system firmware version is not at 7.4.7, then perform Upgrading System Firmware.
Upgrading System Firmware using CLI
Do not downgrade the version of the system firmware. Doing so would result in ILOM no longer working,
requiring you to replace hardware.
If any error occurs during the firmware upgrade, you can reset the Service Controller through ILOM CLI
using the resetsc command:
sc> resetsc
Are you sure you want to reset the SC (y/n)? y
If this command also fails, contact your next level of Sonus Support.
Perform the following procedure to upgrade the system firmware using the CLI:

2.
# unzip 147309-09.zip
This places the sysfwdownload and the Sun_System_Firmware-7_4_7-Netra_T5220.pkg files

in the /export/home/packages/147309-09 directory.
The 147309-09.zip file is also available from the Sonus Salesforce Customer Portal at WL9.3.
# cd /export/home/packages/147309-09
# ./sysfwdownload Sun_System_Firmware-7_4_7-Netra_T5220.pkg
.......... (6%).......... (13%).......... (19%).......... (26%)..........

(33%).......... (39%).......... (46%).......... (52%)..........
(59%).......... (66%).......... (72%).......... (79%)..........
(86%).......... (92%).......... (99%).. (100%)
Download completed successfully.

4. From the host (Solaris domain) shut the system down.
# shutdown -i0
The following message is displayed:
Shutdown started. Friday, May 24, 2013 2:47:53 AM EDT

Broadcast Message from root (pts/2) on crown Fri May 24 02:47:54...
The system crown will be shut down in 1
minute
showmount: crown: RPC: Program not registered
seconds
Do you want to continue? (y or n): y
THE SYSTEM
crown IS BEING SHUT DOWN NOW ! ! !
Log off now or risk your files being damaged
Changing to init state 0 - please wait
5.

5. Establish a connection to the Service Processor via ssh or using the Serial Console port.
Ok prompt appears. At the ok prompt, access the System Controller CLI by using the console escape
characters.
The character sequence "#." is usually used.
{0} ok #
.
You can see one of the following three prompts depending on from where you got into OS console.
a. login:
b. {0} ok
Serial console stopped.
–>
c. {0} ok
Serial console stopped
sc>
6. After performing step 5, If you are landed in option a.login:(login) prompt:
a. Login using the user name/password as root/changeme.
ORACLESP-0833FM9007 login: root

Password:
Waiting for daemons to initialize...
Daemons ready
Oracle(R) Integrated Lights Out Manager
Version 3.0.12.4.y r77080
Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
Warning: password is set to factory default
b. Check whether the admin user is created by executing the following command:
-> cd /SP/users/
-> ls
c. If admin user is created already, proceed to step 10.

d. If admin user is not created, you need to create admin user, proceed to step 9.
7. After performing step 5, If you are landed in option b. –>: iLOM prompt
a. Check whether the admin user is created by executing the following command:
-> cd /SP/users/
-> ls
b. If admin user is created already, proceed with step 10.

c. If admin user is not created, you need to create admin user, proceed to step 9.
8. After performing step 5, If you are landed in option c. sc>: super console prompt, proceed to step 11.
9. You need to create a user name as admin, set the admin account role to Administrator and the CLI mode to

9.
ALOM.
create /SP/users/admin
Creating user...
Enter new password: ********
Enter new password again: ********
Created /SP/users/admin
-> set /SP/users/admin role=Administrator
Set 'role' to 'Administrator'
-> set /SP/users/admin cli_mode=alom
Set 'cli_mode' to 'alom'
10. Exit by using logout command and login as admin user.

11. From the Service Processor CLI, enter the power off command.
sc> poweroff
Are you sure you want to power off the system [y/n]? y
Chassis | critical: Host has been powered off
12. Ensure that your virtual keyswitch setting is not in the LOCKED position.
You can check the setting from the Service Processor CLI with the following command:
sc> showkeyswitch
If the virtual key switch is in LOCKED position you can change that with the
following command:
sc> setkeyswitch -y normal
13. Flash update the downloaded Sun System Firmware image:
sc> flashupdate -s 127.0.0.1

'127.0.0.1' is the default address for the local host.
NOTE: A flashupdate takes about 6 minutes to load a new file. Some commands
are disabled until the file load is complete. The SC will be reset to complete
the upgrade.
Are you sure you want to load the specified file (y/n)? y
Enter y. The following prompt is displayed:
ORACLESP-1116FM901F login:.
14. Log into the ALOM CLI shell (indicated by the -> prompt) from the ALOM login prompt. Login as admin user.

14.
ORACLESP-0833FM9007 login: admin

Password:
Daemons ready
Oracle Integrated Lights Out Manager
Version 3.0.0.0
Use is subject to license terms
15. Power on the service controller and go to the console.
sc> poweron
sc> Chassis | major: Host has been powered on
16. To go to console, type console on the sc prompt. Login to console as root user.
sc> console
Enter #. to return to ALOM.
Done
0:0:0>Network Interface Unit Port 0 Tests ..Done
0:0:0>Extended Memory Tests....Done
ChassisSerialNumber 0833FM9007
A series of events appear till the console login comes.
.................................
activity, system personnel may provide the |
| evidence of such monitoring to law enforcement officials. |
|-----------------------------------------------------------------|
console login: root
password:
17. Verify whether the software firmware is upgraded by entering the following command:
# prtdiag -v | grep "Sun System Firmware"

If you receive a warning message "showmount:RPC: Rpcbind failure - RPC: Unable to receive",
while performing upgrade, you can ignore the warning message.
Upgrading System Firmware using the Web Interface
You can also upgrading using the Web Interface. If the system firmware version is less than V7.4.7, perform the
following procedure to update the system firmware with the Web interface.
Perform the following procedure to update the system firmware with the Web interface:
1. After you unzip the file 147309-09.zip, download the

1.
Sun_System_Firmware-7_4_7-Netra_T5220.pkg file to your local system.
2. Log in to the Netra T5220 as root.
3. In your web browser, type the SP IP address in the location bar. The web interface login page appears.
4. Enter the User Name (default name is root) and the Password (default is changeme), and click the Log In.
5. Click on the Remote Control tab.
6. In the Remote Control tab, click on the Remote Power Control sub-tab.
7. In the Remote Power Control sub-tab, select Graceful Shutdown and Power Off from the pull-down list.
8. Click the Save.
A dialog box appears, asking you to confirm that you want to perform the graceful shutdown and power off.
9. Click OK in the pop-up window.
10. Click on the Maintenance tab.
11. In the Maintenance tab, click on the Firmware Upgrade sub-tab.
12. In the Firmware Upgrade sub-tab, click the Enter Upgrade Mode button.
A dialog box appears, asking you to confirm that you want to enter Upgrade mode.
13. Click the OK button.
14. Click browse and navigate to the directory on your local system containing the firmware file and select
Sun_System_Firmware-7_4_7-Netra_T5220.pkg.
15. Click the Upload button. The file is uploaded. This should take about a minute.
The Firmware Verification page appears.
16. In the Firmware Verification page:
a. Select Preserve Configuration to keep your existing ILOM configuration settings.
b. Click Start Upgrade.
A progress message indicates that the firmware image is being updated. When the update process
reaches 100 percent, an upgrade complete message appears.
17. Click the Reconnect link.
18. In the web interface login page, enter the User Name (default name is root) and the Password (default is
changeme), and click the Log In.
19. In the System Information tab, click on the Overview sub-tab.
20. Verify that the Sun System Firmware version displayed is 7.4.7.
23. In the Remote Power Control sub-tab, select Power On from the pull-down list and click Save.
If you receive a warning message "showmount:RPC: Rpcbind failure - RPC: Unable to

receive", while performing upgrade, you can ignore the warning message.
Step 4: Upgrading the Database Software
ID/trace
Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700

Before performing a database software upgrade, login as user 'insight' and stop EMS and all its processes
by performing the following steps:
$ cd /export/home/ems
$ ./sonusEms stop
Verify that the EMS_SonusDBPackage_solaris-V09.03.00R000.tar is available at /export/home/oracle.

For details, see Downloading Upgrade Files.
If the preInstall.pl displays an earlier oracle version earlier than 11.2.0.3.0 or if you have not
applied the latest Security Patch Update, then follow the below procedure to upgrade the database to 11.2
.0.3 and apply the latest Security Patch Update (SPU).
Perform the following procedure to upgrade the oracle database:
1. Log on as root. (Command: su - root).

2. Navigate to the following location where Insight package is copied.
# cd /export/home/install/ems/oracle
Enter the following command:
# ./UpgradeOracle.sh
The UpgradeOracle.sh script upgrades the Oracle and starts the Oracle. This script takes
approximately one hour to complete.
3. Traverse to the directory /export/home/oracle and remove the downloaded

EMS_SonusDBPackage_solaris-V09.03.00R000.tar file, by executing the following steps to reclaim
free space:
# cd /export/home/oracle
# rm -f EMS_SonusDBPackage_solaris-V09.03.00R000.tar
The following procedure lists how to run the mainInstall.pl script:
1.

1. Before running the mainInstall.pl script ensure that the directory /export/home/install/ems/
contains the required files that were downloaded from the Sonus Salesforce Customer Portal and extracted
here. Ensure that the oracle database instance is also running on server.
2. In order to produce a log of the upgrade, use the /usr/bin/script command to create a record of the
terminal session. This command creates a sub-shell where you run the installation.
When it completes, type exit to terminate the script command.
As super user, enter the following command:
3. Start the mainInstall.pl by entering the following command:
perl mainInstall.pl
*******************************************************
** EMS mainInstall.pl for target release version V09.03.00R000
**
** Run this script AFTER executing preInstall.pl and following instructions
from preInstall.pl
********************************************************************************Starting
mainInstall.pl execution on : Friday, April 04, 2014 5:15:15 AM EDT.
Using "<host_name>.emsConfig.tar" file in "/export/home/backup" directory.

Do you want to download "<host_name>.emsConfig.tar" file from remote host
(y/n/Y/N)? (default:Y):
Enter Y if you want to download the file from the remote host. You will be prompted to enter the following
details:
- Remote sftp host name or IP
- Username for sftp
- Login Password
- Directory on remote host
Or

Enter N, if you do not want to download the file from the remote host using the script.
You have to download the <host_name>.emsConfig.tar file manually and place it at
/export/home/backup.
It is required to use the <host_name>.emsConfig.tar generated from the same system.
Using "<host_name>.backupData.tar" file in "/export/home/backup" directory.

Do you want to download "<hostname>.backupData.tar" file from remote host
details:
- Username for sftp
- Login Password
Or
You have to download the <host_name>.backupData.tar file manually and place it at
If you have not upgraded the Solaris and Oracle to the recommended versions before running the
mainInstall.pl script, the script will indicate the same and terminate. You must upgrade the Solaris
and Oracle to the required version and re-run the script.
For information on installing the Solaris Patch and Oracle Database and any other Third party software, refer
to Upgrading the Third Party Software.
The following message appears, if Solaris OS and Oracle are not upgraded:
Please re-run mainInstall.pl after following above instructions.

Exiting...
The script will continue importing data and then restart EMS. The procedure may take around 60 minutes for
an 80 MB DB data.

Checking solaris OS patch...
Checking Database version...
Running emsInstall.sh...
The PSX Manager is not included on this media and will not be installed.
Please contact your Sonus representative.
The BRX Manager is not included on this media and will not be installed.
Current and New JBOSS version: 5.1.0-GA::5.1.0-GA09.03.00R000
Removal of <JBSSsrvr> was successful.

Installation of <JBSSsrvr> was successful.
Setting up user 'insight' OS privilege ...
insight
Check for incompatible packages for Insight agent ...
Local Number Portability Application(Tools-> LNPAdaptor) is not being

deployed.
If you need to deploy it, please run the following script as 'root' user:
/export/home/ems/conf/deployLNPApplication.sh
********************
Uninstalling SONSems
********************
The uninstall may take several minutes to complete if there are many PM
archive files.
Shutting down Sonus Insight and related components!
9. The mainInstall.pl script runs to completion with the following message:
mainInstall is complete. Run postInstall.pl to continue.

Completed mainInstall.pl execution on : Fri Mar 1 20:43:41 IST 2013
10. After the mainInstall.pl execution is complete, it indicates the same and instructs you to run the
postInstall.pl.
Running the postInstall.pl

Running the postInstall.pl may approximately take one minute.
Perform the following procedure to run the postInstall.pl script:
1. Run the postInstall.pl script by entering the following command:
perl postInstall.pl
*******************************************************
** EMS postInstall.pl for target release version V09.03.00R000
**** Run this script AFTER executing mainInstall.pl

****************************************************************
Starting postInstall.pl execution on : Friday, July 15, 2011 3:19:11 AM EDT
2. After postInstall.pl execution is complete, the following message appears:
postInstall is complete. Current EMS version is V09.03.00R000
Completed postInstall.pl execution on : Friday, July 15, 2011 3:19
3. Type exit to exit from the script.

4. All the script logs are available in logs/ directory and in the file that you have mentioned while starting the
script command.
If SGX4000 device is configured on pre-V09.03.00 Insight system, you have to perform the following
procedure during data migration from any pre-V09.03.00 Insight system to Insight V09.03.00.
1. a. Login to Insight.
b. Navigate to Network Mgmt > Insight Administration.
c. Select the registered SGX4000 node from the Navigation tree.
d. Modify and Update the following (default) values if required.
i. SSH Port
ii. Login (CLI)
iii. Password (CLI)
e. Click on Update and then click on Discover node.
Upgrading PSX Manager GUI on Insight EMS Server
The PSX Manager GUI installer is a part of EMS.V09.03.00R000.tar.Z file. If the PSX Manager GUI version is not
V09.03.00R000, then it can be installed separately.
Perform the following procedure to install the PSX Manager GUI:
1.

1. Login to the shell on the Insight EMS server as root user.
2. If the /export/home/install/ directory is not available, create the directory by executing the following
command.
# mkdir -p /export/home/install/
3. Download the SSGUI_V09.03.00R000.tar file from the Sonus Salesforce Customer Portal to
/export/home/install/ directory on the Insight EMS server.
4. Change the directory to /export/home/install/ by executing the following command:
# cd /export/home/install/
5. Untar the SSGUI_V09.03.00R000.tar file by executing the following command:
# tar -xf SSGUI_V09.03.00R000.tar
package.
# ./GuiClient.sh
# pkginfo -l SONSpsx
8. Login to Insight EMS GUI.

9. Click the Insight Administration icon on the left pane.
11. Click the Reload button to integrate the new PSX Manager version to Insight EMS Server.
12. Access the PSX Manager graphical user interface (GUI) by clicking on Element Mgmnt > PSX Manager icon
on the left pane.
Post Upgrade Tasks
For more information on Post-Install/Upgrade tasks, see Performing Post-Upgrade Tasks on SA Solaris.
If you experience any issues in your production network following an upgrade, you can return to the previous version
of Insight by using the following procedure:
1. Pre-requisites for Rollback using Disk Mirroring are completed successfully prior to start of upgrade.
2.

2. If upgrade fails to complete successfully, perform the following to roll back to old EMS version.
a. Stop Insight EMS by executing the following command:
# su - insight -c "./sonusEms stop"
b. Mount Mirrored disk.

The ‘/’ slice on the mirrored disk need to be mounted locally in order to edit two files on the /etc path
(which lives of ‘/’slice).
Use the following commands to determine the slice where the '/' path lives.
# conf="/opt/SONSdmems/config/platform_T5220-4.conf"
# echo "`grep \"svm.slave.disk\" $conf|head -1|awk -F= '{print $2}'|tr -d
' '`s0"
In this example, above commands return the output as c1t2d0s0.

Once the slice is determined, execute the following as root user.
# mount /dev/dsk/<disk> /mnt
where <disk> should be replaced with output of previous command.

Example:
# mount /dev/dsk/c1t2d0s0 /mnt
c. Edit /mnt/etc/vfstab
In order to preserve previous release config, the previous (before mirroring was first setup) vfstab file
need to be restored.
# cd /mnt/etc
# cp -p vfstab.orig vfstab
# chown root:sys vfstab
Find the disk labels for disks at slots 0 and 1 using following command:
# echo | format

In this example, above command lists following disks:
AVAILABLE DISK SELECTIONS:

0. c1t0d0 <SUN146G cyl 14087 alt 2 hd 24 sec 848>
/pci@0/pci@0/pci@2/scsi@0/sd@0,0
Disk at slot 0 is c1t0d0 and disk at slot 1 is c1t1d0.

Replace disk labels present in vfstab file to match with the ones found using above command.
The /mnt/etc/vfstab should not contain disk mirroring information and should look like the
example below.
#device device mount FS fsck mount

mount
#to mount to fsck point type pass at boot
options
#
fd - /dev/fd fd - no -
/proc - /proc proc - no -
/dev/dsk/c1t0d0s1 - - swap - no -
/dev/dsk/c1t0d0s0 /dev/rdsk/c1t0d0s0 / ufs 1
no -
/dev/dsk/c1t0d0s3 /dev/rdsk/c1t0d0s3 /var ufs 1
no -
/dev/dsk/c1t0d0s4 /dev/rdsk/c1t0d0s4 /export/home ufs 2
yes -
/dev/dsk/c1t1d0s1 /dev/rdsk/c1t1d0s1
/export/home/ems/weblogic/sonusEms/data ufs 2 yes -
/export/home/oracle/oradata ufs 2 yes -
/dev/dsk/c1t1d0s0 /dev/rdsk/c1t1d0s0 /export/home2 ufs 2
yes -
/dev/dsk/c1t0d0s6 /dev/rdsk/c1t0d0s6 /opt ufs 2
yes -
/devices - /devices devfs - no -
sharefs - /etc/dfs/sharetab sharefs - no -
ctfs - /system/contract ctfs - no -
objfs - /system/object objfs - no -
swap - /tmp tmpfs - yes -
The entry for /export/home2 and /export/home/ems/weblogic/sonusEms/data sh

ould have the label for disk at slot 1 and rest of the entries should have the label for disk at
slot 0.
d. Edit /mnt/etc/system as root user and delete the following lines if present:

d.
* Begin MDD root info (do not edit)

rootdev:/pseudo/md@0:0,100,blk
* End MDD root info (do not edit)
Save the file changes

e. Unmount /mnt as root user:
# cd
# umount /mnt
f. Physically swap disks and reboot system:

i. Shutdown the system by running following command as root user:
# init 5
ii. Perform disk swap.
Swap disks in slot 0 with the disk in slot 2.

Disks initially at slots 0 and 1 should be inserted back to slots 2 and 3. Otherwise, it
will result in system booting in maintenance mode.
iii. Power up and reboot the system.

This would result in the system booting from the pre-upgrade configuration.
If performing the rollback on an HA EMS configuration, then allow the Active server to
completely recover before powering on the Standby server.
g. Verify mirror status.
After the reboot, run the 'metastat' command as root user to verify that disks are in detached mode
(disks not being mirrored):

# metastat -c
d201 m 60GB d21
d21 s 60GB c1t1d0s1
d200 m 219GB d20
d20 s 219GB c1t1d0s0
d106 m 2.0GB d16
d16 s 2.0GB c1t0d0s6
d105 m 50GB d15
d15 s 50GB c1t0d0s5
d104 m 202GB d14
d103 m 4.0GB d13
d100 m 5.0GB d10
d101 m 15GB d11
d11 s 15GB c1t0d0s1
d41 s 60GB c1t3d0s1
d35 s 50GB c1t2d0s5
d31 s 15GB c1t2d0s1
h. Dump device need to be set to the original device (e.g. /dev/dsk/c1t0d0s1 for the example above)
using the following command:
# dumpadm -d /dev/dsk/c1t0d0s1
i. If you need to restart disk mirroring, clear the metadb and enable the disk mirroring using dmctl. The
mirrors can be cleared using command metaclear
# metaclear d41
# metaclear d40
# metaclear d36
# metaclear d35
# metaclear d34
# metaclear d33
# metaclear d30
# metaclear d31
# metaclear -r d201
# metaclear -r d200
# metaclear -r d106
# metaclear -r d105
# metaclear -r d104
# metaclear -r d103
# metaclear -r d100
# metaclear -r d101

j. Execute the following command to list all the existing metadb state database replicas.
# metadb
Output will be similar to the following:
flags first blk block count

a m pc luo 16 8192 /dev/dsk/c1t2d0s7
a pc luo 8208 8192 /dev/dsk/c1t2d0s7
k. Clear all the metadb state database replicas using the following command:
# metadb -df <replica1> <replica2> <replica3> <replica4>.
l. In the above example, replicas are cleared using command:
# metadb -df c1t2d0s7 c1t0d0s7 c1t3d0s7 c1t1d0s7
m. Execute following command to verify that all mirroring configurations are cleared. These commands
should not display any database replicas.
# metastat -c
# metadb -i
n. Re-enable disk mirroring by following Enabling Disk Mirroring.
There will be downtime during the procedure since server will be rebooted as part of re-enabling disk
mirroring.
Performing Post-Upgrade Tasks for Standalone Solaris

After upgrading EMS Standalone Solaris to V09.03.00, performing the following task.

Installing the PSX Manager GUI on Solaris SA
Installing the PSX Manager GUI on Solaris SA
Perform the following procedure to install the latest version of PSX Manager GUI:

2. If the /export/home/install/ is not available, create the directory by using the following command:
3. Download the SSGUI_V09.03.00R000.tar file from Sonus SalesForce Customer portal to local system.
4. Copy the SSGUI_V09.03.00R000.tar file from the local system to the /export/home/install/
directory on the Insight EMS server.
# tar -xvf SSGUI_V09.03.00R000.tar
7. Change the directory to /export/home/install/SSGUI by executing the following command:
# cd /export/home/install/SSGUI
package.
# ./GuiClient.sh
9. The system prompts the following message:
Version V09.0x.00 already exists. It must be removed to proceed.

Remove the existing version? (default: N) [y|Y,n|N]:
Enter Y to proceed with the installation.


11. Login to the Insight EMS graphical user interface (GUI).

15. Access the PSX Manager graphical user interface (GUI) by clicking on Element Mgmnt > PSX Manager
icon on the left pane.
Managing Insight Account Names and Passwords-SA Solaris
This section provides a summary of the account name and password information associated with the Insight. In
particular, the following items are included:
Table of Contents
Changing the Netcool Object Server Name
Default Account Names and Passwords-SA Solaris
Procedures for Changing Passwords-SA Solaris
Changing the Netcool Object Server Name

Sonus provides the name “SONUSDB” to the Netcool object server. This default name must be changed to connect
the EMS Netcool database directly with the Netcool implementation, perform the following procedure:
1. Login as insight user.

2. Enter the following command to stop the netcool FM process in the system:
# /export/home/ems/sonusEms stop fm
# cd /export/home/ems/conf
# ./netcool_rename_db.ksh
5. After the script executed successfully, start the netcool FM process in the system.

5.
# /export/home/ems/sonusEms start fm
6. For an HA configuration, ensure you perform Steps "1" to "5" on each node one by one.
Rollback Mechanism
To change the netcool object server name to default or old name, use the same script and provide the required
choice for old and new server name as input.
Object Server Name Restriction
The new object server name must meet the following criteria:
Maximum of 11 characters in length.

The first character must be an uppercase letter.
The characters can be uppercase letters, underscores, or numbers.
For more information, see IBM documentation.
Limitation
Upgrade operation is not supported with the changed netcool object server name. In order to support, you
need to first rollback to default netcool object server name “SONUSDB”.
Making a node standalone from high availability configuration is not supported with the changed netcool
object server name. In order to support, you need to first rollback to default netcool object server name
“SONUSDB”.
Default Account Names and Passwords-SA Solaris

Insight default accounts include those associated with Solaris and those associated with the underlying Insight
database. The Solaris accounts include both those that are common to all Sonus Solaris platforms and those that
are specific to Insight. These default accounts and their associated default passwords are listed in this section.
For the Insight-specific accounts, Release V07.03.00 introduced the option to set “strong” passwords or to keep
existing “weak” passwords. The choice between strong or weak passwords will be given during installations and
upgrades.
The strong passwords have more restrictions than the pre-V07.03.00 passwords and require that a new password
be entered during the installation or upgrade. The strong passwords do not have a default value, while the weak
passwords do have a default value.
Common Sonus Solaris Accounts
root sonus
Insight-Specific Solaris Accounts

insight insight
oracle oracle
dbimpl dbimpl
system manager
admin admin
root sonusfm
Procedures for Changing Passwords-SA Solaris

All Solaris Accounts Except for User "insight"
For all Solaris accounts other than insight, change the password using the Unix “ passwd” command.
restrictions.

Changing Passwords-SA Solaris
The following section provides information regarding various accounts, password restrictions, and procedure to
change the password.
Changing the “insight” User Password and/or Password Expiration Behavior

Procedure
Changing the Insight Database Password
Procedure
Changing the sys Database User Password
Procedure
Changing the system Database User Password
Procedure
Procedure
Procedure
Procedure
Changing the Password or Password Behavior of the "insight" User for the IAS System
Password Preservation Associated With Upgrades
Change the insight user password after an upgrade if you did not use the strong password option when running the
configureJumpstart.sh or emsMigrate.sh script. This changes the insight user password from the
previous value.
expiration values.

CAUTION
You must use the following procedure to change the password for the insight user. Do not use the pass
wd command, which would result in a misconfiguration of Netcool.
The insight user password has the following restrictions (unless you use the -v option described in the
procedure):

– numbers
The password:
cannot be based on a forward or reversed dictionary word.
must contain at least 4 alphabetic characters.
must contain at least 2 special (non-alpha and non-digit) characters.
For additional restrictions, please refer to /etc/default/passwd
Procedure
procedure.
1. Log in as root.
Where:
password.


3.
(Default:Y)
Enter Y.
expiration behavior. Unless you used the -v option in Step "1", the password must meet the restrictions listed
5. When prompted, re-enter the password you entered in Step "4".
If the server is not part of a DR or HA system, continue to Step "9".
Enter Y.

(Default:Y)
(or)
(Default:Y)
(or)
(Default:Y)


procedure):

– numbers
CAUTION
when the IAS is up by performing "Changing the Insight Agent Connection Account Password". If the Insight
database password on the IAS does not match the Insight database password on the Insight server to
which it is registered, the database user (dbimpl) will be locked out of the database, and Insight will not
function correctly. To unlock the database, run the following script: /export/home/ems/conf/unlockDb
implUser.sh
Procedure
(Default:Y)
Enter Y.



password when the IAS is up, see Changing the Insight Agent Connection Account Password. If the Insight
database password on the IAS does not match the Insight database password on the Insight server to which
it is registered, the database user (dbimpl) will be locked out of the database, and Insight will not function
correctly. To unlock the database, run the script
/export/home/ems/conf/unlockDbimplUser.sh.
# /export/home/sonusComm/bin/jash
% logon admin admin
success

3.
where
% exit
Database Password for EMS Standalone System.
following:
database password.

This section describes how to change the sys database user password with the changeSysDbPassword.sh
script.

The sys database password has the following restrictions (unless you use the -v option described in the procedure):

– numbers
Procedure
To change the sys database user password, perform the following:
# ./changeSysDbPassword.sh
The following options may be used when entering the./changeSysDbPassword.sh command:

in "Password Restrictions"
3. When prompted, re-enter the sys database user password.

changeSystemDbPassword.sh script.
The system database password has the following restrictions (unless you use the -v option described in the
procedure):

– numbers

Procedure
The following options may be used when entering the./changeSystemDbPassword.sh command:


This section describes how to change the Netcool database user password for the Insight_Admin_User
with the changeNetcoolDbInsightPassword.sh script.

– numbers
Procedure
To change Netcool Database User Password for the Insight_Admin_User, perform the following:

The following options may be used when entering the./changeNetcoolDbInsightPassword.sh

command:

(Default:Y)
Enter Y.

changeNetcoolDbRootPassword.sh script.
The user password has the following restrictions:

– numbers
Procedure
To change Netcool Database User Password for the root user, perform the following:
1.


(Default:Y)
Enter Y.
Enter the password. The password must meet the restrictions listed in "Password Restrictions"
This procedure can be used after you obtain your own SSL certificate and import it, see SSL Certificate Installation

– numbers
Procedure

2.
Enter the password.

Restrictions.

# ./jash

% logon admin admin
success
where admin is the account name

% exit
When upgrading to Release V09.02.00 and using the “weak” password option (see "“Strong” and “Weak”
Passwords"), use of the documented upgrade procedures will ensure that all default Solaris accounts and
passwords, customer-created Solaris accounts and passwords, and Sonus database accounts and passwords are
preserved across the upgrade.
Upgrading to Release V09.02.00 using the “strong” password option requires the user to create new account
passwords.
Configuring IPv6 on SA Solaris

This section contains the procedure to migrate the EMS in the network from IPv4 to IPv6 addresses.
Enable IPv6 on the EMS Standalone Solaris Server
Re-register the Device with the IPv6 management address from the EMS Node Registration
Window
Prerequisites

Enable IPv6 on the EMS Standalone Solaris Server

After Insight EMS is upgraded to Release V09.02.00, you can move any of the managed IP interface in EMS to IPv6
when the configured Sonus devices are migrated to IPv6. Until the configured Sonus devices are migrated to IPv6,
EMS can continue to manage all the configured devices over the existing IPv4 addresses.
The following procedure describes the procedure to enable IPv6 on the EMS Standalone server.
1. Log in as root.
2. Create the following file:
/etc/hostname6.<interface name>
# ifconfig -a
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232
index 1
inet 127.0.0.1 netmask ff000000
e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 10.54.7.179 netmask ffffffc0 broadcast 10.54.7.191
In this example, e1000g0is the name of the interface on which IPv6 needs to be enabled.
So, create the following file:

/etc/hostname6.e1000g0
3. Add the following entry to the /etc/hostname6.e1000g0 file, save, and exit:
addif <ipv6address>/<prefix> up
For example,
addif FD00:10:6B50:4160::33/60 up
where FD00:10:6B50:4160::33 is the IPv6 address of the server.


4.
You will see that ::1 localhost has been added as the first line.


# svcadm restart network/physical
# ifconfig -a
9. Restart the server as user root using following command:
# reboot -- -r
10. Verify that all EMS services are up after restart using the following command as user insight.
$ /export/home/ems/sonusEms status
After server restart, it will take around 10 minutes for all EMS services to be up and running.
Guide.
Re-register the Device with the IPv6 management address from the EMS
Node Registration Window
After enabling IPv6, you need to re-register (which includes un-registration of IPv4 device, then register device with
IPv6 address where mgmt client is Ipv6) from the EMS node registration window.
1.

1. In the EMS Node Registration window, verify if both IPv4 and IPv6 addresses are displayed.
2. Click Unregister.
3. Click the same device under Unregistered Nodes. Update the management client and device IP with IPv6
address and click the Update button.

Figure 341: Re-registering Device with IPv6
4. Click Register.
Common Administrative Tasks-SA Solaris
This section contains general information on configuration tasks.
Account Management-SA Solaris

Changing Netcool DB Object Server Name for Solaris SA

Disk Mirroring-SA Solaris
Insight Server Administration-SA Solaris
Insight Server Backup and Restore-SA Solaris
Insight Server Database Administration-SA Solaris
Netcool Configuration and Administration Tasks-SA Solaris
Uninstalling Sonus Insight-SA Solaris
Account Management-SA Solaris

This section contains the following account management tasks:
Changing the Root Password Restrictions or Aging

Inactive Account Lockout Configuration
Idle Session Logout
For instructions on how to reset the root password, see All Solaris Accounts Except for User "insight".
The default length of time before a password expires is 90 days. The default password restrictions are given in the
next section.
To change the password restrictions or the length of time before passwords expire, as a user with root privileges,
edit the /etc/default/passwd file. You can either comment out lines that restrict values, or change the restricted
values.
For a description of the /etc/default/passwd file contents, see the Sun Microsystems Solaris 10 Reference
Manual Collection (http://docs.sun.com/app/docs/doc/
816-5165/6mbb0m9nr?a=view#FILES).
restrictions.
By default, an account will be disabled if the user has not logged in within 90 days.
To change the default, edit the /usr/sadm/defadduser file to change the value of
definact=90
to the new value (in days) you desire. If you remove 90 and do not replace it with a new value, then the account
lockout feature will be disabled.
Idle Session Logout
By default, a session that has been idle for 30 minutes will be closed.
To change the default, edit the /etc/profile file to change the value of
TMOUT=1800
to the new value (in seconds) you desire.

To disable the idle session timeout feature, remove the following lines from the /etc/profile file:
TMOUT=1800
export TMOUT
Changing Netcool DB Object Server Name for Solaris SA

name.
1. On EMS server get the netcool DB name from /export/home/netcool/omnibus/db/{DB_NAME}

# /export/home/ems/sonusEms stop
3. As insight user execute the following script:
# cd <BASE_DIR>/conf/
# /export/home/ems/sonusEms start
Limitation

Disk Mirroring-SA Solaris

This section contains procedures for enabling disk mirroring and configuring disk mirroring on Insight servers. The
disk mirroring tool-kit allows you to easily perform many of the software mirroring tasks such as enabling, disabling,
suspending, resuming, and reconfiguring disk mirrors using Solaris Volume Manager (SVM). It performs preliminary
error checking before executing a user command for detection of problems that may result in command failure. The
toolkit can also be used to monitor and report the health of disk mirrors.
Enabling disk mirroring will also make it easier for you to perform a fallback to previous version from future HA
upgrades. If you experience any issues in your production network following an upgrade, you can return to the
previous version of Insight by using the Rollback using Disk Mirroring procedure.
Sonus servers support only software mirroring. This section describes software mirroring only. Insight disk
mirroring is supported only on Netra T5220 four-disk systems.
Disk Mirroring Overview-SA Solaris

Enabling Disk Mirroring-SA Solaris
Checking the Status of Mirrors-SA Solaris
Disabling Disk Mirrors-SA Solaris
Suspending Disk Mirrors-SA Solaris
Resuming Disk Mirrors-SA Solaris
Detaching Slave Disk from the Mirror-SA Solaris
Reattaching Slave Disk to the Mirror-SA Solaris
Replacing Disks-SA Solaris
Monitoring Disk Mirror Health-SA Solaris
Customizing Health Monitoring-SA Solaris
Debug Logs-SA Solaris
Configuring Alternative Boot Device-SA Solaris
Customizing Disk Mirror Configuration-SA Solaris
Disk Mirroring Overview-SA Solaris
Insight supports disk mirroring on Netra T5220 servers that have four internal disks. The following mirrors are set up:
Disk 1 Disk 3
Disk 2 Disk 4
This scheme allows the applications that use the second internal disk to continue using it for its intended purpose.
Each of the two disk mirrors requires the following SVM components:
State Database Replicas – Two on slice 7 of each of the mirrored disks

RAID-0 Volumes – Six concatenation volumes of one slice each (s0, s1, s3, s4, s5, s6) on each of the
mirrored disks
RAID-1 Volumes – Six mirror volumes using RAID-0 volume on the same slice of each of the mirrored disks
After enabling disk mirroring, the disks, mirrors, and submirrors are configured as shown in the following figure
Two-way Disk Mirroring Using SVM.

Figure 342: Two-way Disk Mirroring Using SVM
Table 61: Mirrors and Submirrors on Netra T5220-4 with Mirrored Disks 1 and 3
Master Disk Submirror Name Slave Disk Submirror Name Mirror Name
d10 d30 d100
d11 d31 d101
d13 d33 d103
d14 d34 d104
d15 d35 d105
d16 d36 d106
d20 d40 d200
d21 d41 d201
Enabling Disk Mirroring-SA Solaris
Perform the following procedure on every Insight server on which internal disks mirroring is to be enabled. Disk
mirroring for Insight is supported on Netra T5220 four-disk systems. Before performing an upgrade, ensure that disk
mirroring is enabled.

Caution
Be sure to wait until synchronization completes before performing any other tasks, such as disabling,
suspending, resuming mirroring, configuring, or booting from the alternate boot device.
1. Issue the following command to verify that the Sonus disk mirroring toolkit package is installed:
# pkginfo SONSdmems
application SONSdmems Sonus disk mirroring management tools
The output should indicate that the package is installed.

2. Use the format command to verify that there are four internal disks
Sonus recommends that you first run the dmctl commands in dry-run mode (use the --dryrun option)
to detect problems that would prevent successful mirroring. If the program does not report any fatal
errors, execute the program without the --dryrun option.
Ensure that the drive definitions are of format c1t*d*. If not, edit the /opt/SONSdmems/config/p
latform_T5220-4.conf file and modify the drive definitions accordingly before configuring disk
mirroring.
For example, if the drive definitions are of format c0t*d*, edit the values of svm.master.disk an
d svm.slave.disk to c*t*d* format in the platform_T5220-4.conf file.
3. Execute the following command to enable mirroring of disk 1 and disk 3:
# /opt/SONSdmems/bin/dmctl --id=1 enable
>>>Ready to create one way mirror<<<

Do you want to continue? [yes|no|quit]
Enter yes.
>>>Slave disk c1t2d0 will now be reformatted<<<

Enter yes.

6.
>>>The server will now be rebooted to use the mirrors <<<

The
mirror configuration has been changed. The system should now use the
mirrors but will continue to use the logical devices until rebooted.
Enter yes.
The server is rebooted.
Server will automatically reboot after a few minutes and you will loose connectivity. Please wait for
the reboot to complete. Login to the server back again after the reboot completes, and continue with
the next step.
7. After the server comes up, execute the following command:
>>>Ready to create two way mirror<<<

Enter yes.
9. Use the metastat command to check the status of mirrors.
# metastat -c
Verify that the submirrors show a resync percentage. For example, the following appears:

d106 m 2.0GB d16 d36 (resync-0%)
d105 m 50GB d15 d35 (resync-0%)
d15 s 50GB c1t0d0s5
d35 s 50GB c1t2d0s5
d104 m 59GB d14 d34 (resync-0%)
d14 s 59GB c1t0d0s4
d34 s 59GB c1t2d0s4
d103 m 4.0GB d13 d33 (resync-0%)
d100 m 5.0GB d10 d30 (resync-0%)
d101 m 15GB d11 d31 (resync-0%)
d11 s 15GB c1t0d0s1
d31 s 15GB c1t2d0s1

Enter yes.

Enter yes.

An
attempt to remount the file systems has failed. The system should now
use the mirrors but will continue to use the logical-devices until
rebooted or file systems are successfully remounted.
Enter yes.

the next step.

Enter yes.
# metastat -c
Verify that the submirrors d200 and d201 show a resync percentage. For example, the following appears:
d200 m 76GB d20 d40 (resync-0%)

d20 s 76GB c1t1d0s0
d40 s 76GB c1t3d0s0
d106 m 2.0GB d16 d36 (resync-0%)
d105 m 50GB d15 d35 (resync-0%)
d15 s 50GB c1t0d0s5
d35 s 50GB c1t2d0s5
d104 m 59GB d14 d34 (resync-0%)
d14 s 59GB c1t0d0s4
d34 s 59GB c1t2d0s4
d201 m 60GB d21 d41 (resync-0%)
d21 s 60GB c1t1d0s1
d41 s 60GB c1t3d0s1
d103 m 4.0GB d13 d33 (resync-3%)
d100 m 5.0GB d10 d30 (resync-2%)
d101 m 15GB d11 d31 (resync-0%)
d11 s 15GB c1t0d0s1
d31 s 15GB c1t2d0s1
17. Enable disk mirror error reporting (through email). See Customizing Health Monitoring-SA Solaris.
18. Enable periodic disk mirror error monitoring and reporting (using a cron job). See Monitoring Disk Mirror

18.
Health-SA Solaris.
19. Use the metastat command to check the status of mirrors. Verify that the mirrors are eventually fully
synchronized (the resync-% column will not appear). This may take several hours.
# metastat -c | grep resync
Checking the Status of Mirrors-SA Solaris

Use the following command to examine the status of mirrors and submirrors:
metastat -c
Omit the –c flag to view detailed status.
Use the following command to examine the status of the state database replicas:
metadb -i
Omit the –i flag to view concise status.
Disabling Disk Mirrors-SA Solaris
The following procedures describes how to disable disk mirroring in a four-disk system.
Caution
Disabling disk mirroring stops data synchronization across disk mirrors. For upgrading EMS, disk mirroring
must not be disabled.
1. Execute the following command to disable mirroring of disk 1 and disk 3:
# /opt/SONSdmems/bin/dmctl --id=1 disable
2. When asked if you want to continue, enter yes.



7.


# metastat -c
Suspending Disk Mirrors-SA Solaris
Either the slave or master disk can have its reading/writing of data temporarily suspended (taken offline) at any time,
but both master and slave cannot be suspended at the same time.
To temporarily suspend the reading/writing of data on a master disk, enter the following:
# /opt/SONSdmems/bin/dmctl --id <mirror ID> suspend --master
To temporarily suspend the reading/writing of data on a slave disk, enter the following:
# /opt/SONSdmems/bin/dmctl --id <mirror ID> suspend
Resuming Disk Mirrors-SA Solaris

To resume the reading/writing of data on a master disk, enter the following:
# /opt/SONSdmems/bin/dmctl --id <mirror ID> resume --master
To resume the reading/writing of data on a slave disk, enter the following:
# /opt/SONSdmems/bin/dmctl --id <mirror ID> resume
Detaching Slave Disk from the Mirror-SA Solaris

Detaching disk mirroring is done to break up disk mirroring before starting an upgrade. This procedure has the
advantage that it does not involve a system reboot. Disk mirroring should have been previously setup before this
detach step can be performed.
This procedure should be done on the EMS standalone server that is being upgraded.
1. Confirm that no mirrors are currently syncing (no sync percentages should be displayed in the output below)
by using the following command:
$ metastat -c
d200 m 219GB d20 d40
d106 m 2.0GB d16 d36
d105 m 50GB d15 d35
d15 s 50GB c1t0d0s5
d35 s 50GB c1t2d0s5
d104 m 202GB d14 d34
d201 m 60GB d21 d41
d21 s 60GB c1t1d0s1
d41 s 60GB c1t3d0s1
d103 m 4.0GB d13 d33
d100 m 5.0GB d10 d30
d101 m 15GB d11 d31
d11 s 15GB c1t0d0s1
d31 s 15GB c1t2d0s1
EMS application is running on disk slots 0 and 1, and is mirrored to disks in slots 2 and 3 respectively.
Disks in slots 2 and 3 still maintain the previous (pre-upgrade) EMS setup, and can be used during rollback to
restore the pre-upgrade state.
2. Detach the mirrors so that disk mirroring no longer takes place, using the 'metadetach' command.
Execute the following command:

# metadetach d201 d41
d201: submirror d41 is detached
3. After detaching the mirrors, run the 'metastat' command to see the mirror status. Output should now look like
this:
# metastat -c
d201 m 60GB d21
d21 s 60GB c1t1d0s1
d200 m 219GB d20
d106 m 2.0GB d16
d105 m 50GB d15
d15 s 50GB c1t0d0s5
d104 m 202GB d14
d103 m 4.0GB d13
d100 m 5.0GB d10
d101 m 15GB d11
d11 s 15GB c1t0d0s1
d41 s 60GB c1t3d0s1
d35 s 50GB c1t2d0s5
d31 s 15GB c1t2d0s1
Disks are now detached and mirroring no longer takes place between them.
Do not remove the slave disks (disks at slot 2 and 3) after detaching them from disk mirrors. Doing
so will cause the system to boot in single user/maintenance mode upon executing reboot command.
Reattaching Slave Disk to the Mirror-SA Solaris
This procedure is performed to resume mirroring of a previously detached disk mirror setup. Perform this once the

upgrade has been successfully completed and new functionality is verified to be working.
Running this reattach procedure will start syncing back again without needing a system reboot.
The EMS server continues to function normally during the reattach slave disk process.
1. Verify the current state by executing the following command.

d201 m 60GB d21
d21 s 60GB c1t1d0s1
d200 m 219GB d20
d106 m 2.0GB d16
d105 m 50GB d15
d15 s 50GB c1t0d0s5
d104 m 202GB d14
d103 m 4.0GB d13
d100 m 5.0GB d10
d101 m 15GB d11
d11 s 15GB c1t0d0s1
d41 s 60GB c1t3d0s1
d35 s 50GB c1t2d0s5
d31 s 15GB c1t2d0s1
2. Reattach the mirrors using the 'metattach' command:
# metattach d201 d41

This will start sync process. Run the 'metattach' command to view the progress of the sync.
It will take several (6 - 8) hours for all sub mirrors to sync up to 100%. A percentage will be
displayed for each if the sub mirrors with the current status until they are fully synced.
3. Verify the output using the following command.

3.
The output looks like as below:
d200 m 219GB d20 d40

d106 m 2.0GB d16 d36
d105 m 50GB d15 d35
d15 s 50GB c1t0d0s5
d35 s 50GB c1t2d0s5
d104 m 202GB d14 d34
d201 m 60GB d21 d41
d21 s 60GB c1t1d0s1
d41 s 60GB c1t3d0s1
d103 m 4.0GB d13 d33
d100 m 5.0GB d10 d30
d101 m 15GB d11 d31
d11 s 15GB c1t0d0s1
d31 s 15GB c1t2d0s1
Disks are now synced and getting mirrored successfully.
Replacing Disks-SA Solaris
When a disk fails and is replaced with a new disk, use the following procedure to resume disk mirroring on the new
disk:
1. Locate and verify the disk failure by logging on as root and entering the following command:
# metadb
2. Examine the output and record any failed database replicas.

The following example shows 2 state database replicas each on slice 7 of the local disks c1t0d0 and
c1t1d0. The replicas on c1t0d0s7 are good. The 'W' in the flags field of the c1t1d0s7 slice indicates that
the device has write errors.

a m p luo 16 8192 /dev/dsk/c1t0d0s7
a p luo 8208 8192 /dev/dsk/c1t0d0s7
W p luo 16 8192 /dev/dsk/c1t1d0s7

3. Delete the failed state database replicas.
# metadb -d c1t1d0s7
4. Record the attachment point for the failed disk.
# cfgadm -al
In the following example the entry in the first column (Ap_Id) of the highlighted row is the attachment point for
the failed disk.
Ap_Id Type Receptacle Occupant Condition
c0 scsi-bus connected configured unknown
c1::dsk/c1t0d0 disk connected configured unknown
c2 fc connected unconfigured unknown
usb0/1 unknown empty unconfigured ok
usb2/2 usb-storage connected configured ok
5. Unconfigure the failed disk.
# cfgadm -c unconfigure c1::dsk/c1t1d0
6. Execute the cfgadm -al command again to check the success of the previous operation. The output should
show the state “unconfigured” under the “Occupant” column of the row corresponding to the failed disk.
7. Pull the failed disk out and insert a new disk of the same capacity and physical attributes.
8. Configure the new disk:
# cfgadm -c configure c1::dsk/c1t1d0
9. Execute the cfgadm -al command again to check the success of the previous operation. The output
should show the state “configured” under the “Occupant” column of the row corresponding to the new disk.
10. Repartition the new disk with the partitioning information of the good drive.

10.
# prtvtoc /dev/rdsk/c1t0d0s2 | fmthard -s - /dev/rdsk/c1t1d0s2
11. Add the same number of state database replicas that were deleted in Step "3".
# metadb -a -c 2 c1t1d0s7
12. Identify and record the mirrors and slice information that need to be replaced.
# metastat -c
The first three lines of the metastat output show that mirror d106 and submirror d26 (slice c1t1d0s6) are in
'maint' state. Note the mirror name (d106) and the slice (c1t1d0s6).
d106 m 516MB d16 d26 (maint)

d16 s 516MB c1t0d0s6
d26 s 516MB c1t1d0s6 (maint)
d105 m 109GB d15 d25 (maint)
d25 s 109GB c1t1d0s5 (maint)
d104 m 2.0GB d14 d24 (maint)
d24 s 2.0GB c1t1d0s4 (maint)
d103 m 3.0GB d13 d23 (maint)
d100 m 6.0GB d10 d20 (maint)
d101 m 15GB d11 d21 (maint)
d11 s 15GB c1t0d0s1
13. Run the metareplace command for each of the mirrors and slice:
# metareplace -e d100 c1t1d0s0

This starts the resynchronization of the mirrors.

Monitoring Disk Mirror Health-SA Solaris
To configure a cron job to periodically check the health of software mirrors and report the status in an email:
# /opt/SONSdmems/bin/dmchk enable
2. Enter a reachable remote/local SMTP host and the recipient’s email address to be configured in the
dmchk.conf file (see "Customizing Health Monitoring").
The default cron job is invoked every 30 minutes and the email sent only when errors are encountered. This
behavior can be changed by configuring appropriate parameters in the dmchk.conf file.
Customizing Health Monitoring-SA Solaris

Edit the /opt/SONSdmems/config/dmchk.conf file to supply the reachable remote/local SMTP host and the
recipient’s email address for the cron job that periodically checks the health of software mirrors and reports the
status in an email. You can also change optional parameters in the file.
The following table, shows the parameters that can be configured in the dmchk.conf file.
Table 62: dmchk Configuration File
Parameter Type Default Description

Name
smtp.host Required None The SMTP mail server that is used to email disk
mirror status.
smtp.to Required None Mail recipients. Semi-colon-separated (;) multiple

recipients may be specified.
smtp.from Optional root Email sender. Default (root@hostname)
smtp.timeout Optional 60 SMTP server connection time out.
smtp.debug Optional 0 SMTP debug flag. Change to 1 to debug SMTP

errors.
send.mail Optional 1 0 - Do not send email
1 - Send mail on error
2 - Always send mail
User supplied — email option overrides it.
cron.job Optional 15,45 * * * * /opt/SONSdmems/bin/dmchk Cron entry to monitor/report disk mirror status
monitor 2>/dev/null 1>&2 every 30 minutes.
Sample Configuration File
The following shows an example display for a dmchk.conf file. (To change the setting in a line, you must

uncomment the line (remove the #)).
# cat /opt/SONSdmems/config/dmchk.conf
# SMTP mail server that is used to email disk mirror status (Required)
#
# The host must be reachable.
#
# Remove the leading # and configure appropriate hostname or IP address
#
#smtp.host = plato
# Mail recipients (Required)

#
# Semi-colon (;) separated multiple recipients may be specified
#
# Example:
#
# smtp.to = john@doe.com;jane@doe.com
#
# Remove the leading # and configure appropriate 'to' addresses
#
#smtp.to = hdaharwal@sonusnet.com
# The email originator (Optional)

#
# default: root (@<hostname> is automatically attached as suffix)
#
#smtp.from = root
# SMTP server connection time out (Optional)

#
# default: 60 seconds
#
#smtp.timeout = 60
# SMTP debug flag (Optional)

#
# default: 0 - Change to 1 to debug SMTP errors
#
#smtp.debug = 0
# Email control flag (Optional)

# Possible values:
# 0 - Do not send email
# 1 - Send mail on error
# 2 - Always send mail
#
# default: 1
#send.mail = 1
# Cron entry to monitor/report disk mirror status (Optional)

#
# default: Every 30 minutes check the status of mirrors
#
#cron.job = 15,45 * * * * /opt/SONSdmems/bin/dmchk monitor 2>/dev/null 1>&2
Debug Logs-SA Solaris

The debug logs for the dmctl program (enabling, disabling, repairing disk mirroring) and for the dmch program
(monitoring status of disks and mirrors) are stored in the directory /opt/SONSdmems/log.
Configuring Alternative Boot Device-SA Solaris
After enabling mirroring of the boot disk, Sonus recommends that the mirror of the boot disk be configured as an
alternate boot device in the NVRAM. Use the following procedure:
1. Enter the following to find the alternate boot device:
# /opt/SONSdmems/bin/dmctl altbootdev
2. Record the device ID listed in the last line of the output.

3. From the console, bring down the server to the ok prompt:
# init 0
4. Check the current boot device:
ok printenv boot-device
boot-device = disk net
5. Create an alias using the device ID recorded in Step 2:
ok nvalias disk2 <device ID>
6. To verify that the alias was created, enter:
ok printenv nvramrc
The following should be displayed:
nvramrc = devalias disk2 <device ID>
7. Set the boot device:
ok setenv boot-device disk disk2 net
The following is displayed:

boot-device = disk disk2 net
ok nvstore
9. Boot normally or from the alternate boot device:

To boot normally, enter:
ok boot
To boot from the alternate boot device, enter:
ok boot disk2
Customizing Disk Mirror Configuration-SA Solaris
The default disk mirroring settings can be changed by editing the platform-specific configuration file, which is located
in the directory /opt/SONSdmems/config.
The platform-specific configuration file name is automatically derived by the program, if not supplied by the user.
The naming convention for the file name is as follows:
platform_ptype-ndisks.conf
The –ndisks portion of the filename is used only when platform_ptype.conf file is not found.
For example, for a four-disk T5220, if the user has not supplied the configuration file, the program first searches for
platform_T5220.conf. If the file is not found, the program then searches for platform_T5220-4.conf.
The platform specific configuration file can have multiple mirror configurations. The following table, lists the
parameters that can be configured for each mirror configuration.
Parameter Name Type Default Description
svm.mirror.id Required None Mirror configuration ID
svm.master.disk Required None Master Disk (cXtYdZ)
svm.slave.disk Required None Slave Disk (cXtYdZ)
svm.master.replica.slice Optional 7 The slice on which master disk state database replicas are created
svm.slave.replica.slice Optional 7 The slice on which slave disk state database replicas are created
svm.replica.count Optional 2 The number of state database replicas

svm.submirror.slice Optional 0,1,3,4,5,6 The slices on which submirrors are created or the slices that are mirrored
The following shows an example display for a platform-specific configuration file.
# cat /opt/SONSdmems/config/platform_T5220-4.conf
# Each mirror configuration must start with the mirror id
# Anything that follows the mirror id belongs to that mirror.
# ---------------------------------------------------------------------
# DISK 1 <-> DISK 3 MIRROR CONFIGURATION
# ---------------------------------------------------------------------
# The mirror ID (Required)
svm.mirror.id = 1
# The master disk (Required)
svm.master.disk = c1t0d0
# The slave disk or master disk mirror (Required)
svm.slave.disk = c1t2d0
# ---------------------------------------------------------------------
# ---------------------------------------------------------------------
svm.mirror.id = 2
# The slave disk (Required)
Insight Server Administration-SA Solaris


Checking the Status of the Insight Server
Changing the IP Address of Insight
Changing the host name for Insight without Changing the IP Address
$ pkginfo -l SONSems
Expected output:

PKGINST: SONSems
NAME: Sonus Insight
CATEGORY: application
ARCH: sparc
VERSION: V09.03.00R000
BASEDIR: /export/home
VENDOR: Sonus Networks Incorporated, Westford, MA, USA.
PSTAMP: emsbuildsrvr20140619031850
INSTDATE: Jun 29 2015 04:42
STATUS: completely installed
FILES: 24172 installed
pathnames 7
linked files 1780
directories 3288
executables 4850805 blocks used (approx)
$ ./sonusEms status
$ ./sonusEms start
The first time that the Insight server is started, a maximum of 30 minutes will be allowed before the startup process
is timed out. On subsequent startups, the maximum time allowed will be equal to 120 percent of the initial startup
time. For example, if the initial startup took 300 seconds, then the maximum time allowed for subsequent startups
would be 360 seconds.
When FM Trap Receiver or EMS is restarted, FM Trap Receiver drops traps received from FM until Netcool
Probe registers to FM. The loss of alarms can be for a period of 10 seconds when FM Trap Receiver (or
EMS) is restarted. Information about the dropped traps can be obtained from log file in the location
/export/home/ems/emsFM/logs/fm_receiver_trace.
# ./sonusEms -help

$ ./sonusEms stop
EMS) is restarted. Information about the dropped traps can be obtained from log file in the location /expor
t/home/ems/emsFM/logs/fm_receiver_trace.
you can change the host name as well as the IP address.
If you want to change the host name of the Insight machine without changing the IP address, do not perform this
procedure. Instead, follow the procedure Changing the host name for Insight without Changing the IP Address.
3. Have your UNIX System Administrator change the address of the system. If you also want to change the host
name of your system, have your UNIX System Administrator change it at this time.
4. As root, change the IP address of the server, change the IP address in the database tables, and update the
Netcool license information as follows:
# cd /export/home/ems/conf/

Changing IP address to '<ip_address>'.

b. Respond y.
Several messages appear, ending with:

Completed changing IP address to '<ip_address>'.
Please refer /export/home/ems/logs/changeIpAddress.log for details.
c/hosts
$ /export/home/ems/sonusEms start
6. For any IAS that is registered to the Insight server, you will be prompted for the root password of the IAS
server. Enter the root password of the IAS server.
The Insight IP address on the IAS is then automatically updated to the new IP address of the Insight server.
7. Start Insight.
In the event you need to change the host name of your Insight server but you are not changing the IP address,
If you are changing both the IP address and the host name of the Insight machine, do not perform this
procedure. Instead, follow the procedure Changing the IP Address of Insight.

2. Have your UNIX System Administrator change the host name of the system.
letters [a-z], digits [0-9], and hyphen[-]. The hostname cannot start with a digit or hyphen, and
cannot end with a hyphen.
Enter the following commands:


Respond y.

After hostname is changed, ensure that the hostname entry exists or is same as in the /etc/hosts

The new host name is automatically put into the appropriate files. The IP address of the system is not
changed.
Insight Server Backup and Restore-SA Solaris

backup files.
Depending on the EMS Software Release (pre-9.2 EMS Solaris, EMS Solaris 9.2.0, or EMS Solaris 9.2.1 and
above) from which backup is taken, the dmp file names would differ.

Table 63: Backup Files Generated
When Backup is Taken from Backup Files generated are Restoring the backup files
EMS Solaris
Pre-9.2.0 Release backupFiles.tar Restore the backup files to 9.2.0 Release.
exp_data_manual.dmp High-level Steps:
exp_strct_manual.dmp 1. Perform a backup of EMS pre-9.0.0

release.
2. Kickstart with EMS 9.2.0 Release.
3. Restore the backup files to 9.2.0
Release.
4. Upgrade from EMS 9.2.0 to 9.3.0
Release.
9.2.0 Release backupFiles.tar Restore the backup files to 9.2.0 Release.
expdp_data_manual.dmp High-level Steps:
expdp_strct_manual.dmp 1. Perform a backup of EMS 9.2.0 release.

2. (Optional) Kickstart with EMS 9.2.0
Release if the EMS Solaris system is
not stable.
Release.
Release.
9.2.1 Release and above backupFiles.tar Restore the backup files to 9.3.0 or 9.2.x
(including 9.3.0 Release) sustaining Release.
High-level Steps:
1. Perform a backup of EMS 9.3.0 or 9.2.x
expdp_strct_manual.dmp sustaining release.
2. Restore the backup files to 9.3.0 or 9.2.x
sustaining release.
System Backup
Sonus recommends that you backup the system daily.
To backup the system, perform the following:
Run the manualBackup.sh script using the following commands:

to store your backup files. Use a directory that is external to the Insight machine. Use a directory name that will
clearly identify the EMS server that created the backup files. Make a note of the directory path because you will
need it later if you need to restore the system.
1. (Optional) Kickstart the EMS Solaris system with respective EMS Release from which backup was taken, if
the EMS Solaris system is not stable. For more details, about EMS Release from which you want to kickstart,
refer the above Table.
a. As root, enter the following commands:

b. The following message appears:

Respond y.

c.
d. Configure the system and perform post-installation tasks..
2. Log in as root.
3. From the backup directory you used for this EMS server in System Backup, copy the dmp files to the
/export/home/oracle/backup/dump directory. Also, copy the backupFiles.tar file to the /tmp
directory.
If the dmp files are copied to /export/home/oracle/backup/dump using an unconventional method,
To change the owner and group of files to Oracle and DBA, enter the following commands.
If backup is taken from pre-9.2.0 then use the following dmp file names:
# cd /export/home/oracle/backup/dump
# chown oracle:dba exp_data_manual.dmp exp_strct_manual.dmp
or
If backup is taken from 9.2.0 then use the following dmp file names:
or
If backup is taken from 9.2.1 or above Release (including 9.3.0 Release) then use the following dmp
file names:
CAUTION
You must copy files from the backup directory that you used for this EMS server. If you use a
backup directory that contains files from another EMS server, Insight will not behave properly.

# cd /export/home/ems/conf/jumpstart
# ./emsMigrate.sh
5. The script informs you that you must have the three files mentioned in Step 3 and asks if you want to
continue. Answer y and press Enter.
6. The script asks for the full path to the backup tar file. Answer /tmp and press Enter.
Do you want to upgrade the system passwords to use strong passwords (production setup) (y|Y) or continue
to use the old weak hardcoded passwords (lab setup) (n|N) (default:Y)?
a. If you want to use strong passwords (recommended for production setup), enter Y and skip to Step 12.
You will enter new passwords.
b. If you do not want to use strong passwords, enter N and continue to Step 8. The old passwords will be
used.
9. When prompted, enter the insight user password.
10. When prompted, re-enter the password you entered in Step 9.
11. When a prompt asks whether you have changed the database sys/system default passwords, perform one of
the following:
If you have not changed the default passwords, enter N and continue to Step 24.
If you have changed the default passwords, enter Y. When prompted, enter the current passwords,
and then continue to Step 24.
When entering strong passwords (Steps 12 through 23), the passwords must meet the
restrictions listed in Changing Passwords.
12. If you entered Y in Step 7, a prompt asks for the Insight database (dbimpl) password. Enter the password.
(The only special characters allowed are _, $, and #.)
14. When prompted, enter the Insight database sys password. (The only special characters allowed are _, $, and
#.)
15. When prompted, re-enter the Insight database sys password.
16. When prompted, enter the Insight database system password. (The only special characters allowed are _, $,
and #.)
17. When prompted, re-enter the Insight database system password.
19. When prompted, re-enter the insight user password.
24. The scripts asks if you want to import the User Activity Logs, PM Stats, and TrunkGroup tables. Answer y if
you want to import these tables; answer n if you do not want to save those tables.

As part of the database upgrade to this version of Insight all Performance
Management database tables will under go a process which
recreates the tables with partitioning. Because this process has the potential
to take a very long period of time Sonus recommends truncating
all of these tables.
Do you wish to truncate these Performance Management database tables and
delete all of their data to avoid the potentially lengthy conversion process?
(default:Y) [y|Y,n|N]'
26. For upgrades from Insight 07.03.06 and above, this message does not apply.
Enter N.
Please reconfirm for truncate before proceeding [y|Y,n|N]
Re-enter the response you gave in Step 25.

Passwords
The emsMigrate.sh script used in the system restore procedure gives you the opportunity to use strong
passwords, which must then be entered and must meet the following restrictions:
The password cannot be the same as the username.

Lowercase letters
Uppercase letters
Numbers
Special characters
Insight Server Database Administration-SA Solaris

This section contains the following Insight server database administrative tasks:

Checking the status of the Database Listener
Manual Backup/Restore of Insight Database
Restoring the Insight Database

1.
$ sqlplus /nolog
SQL> startup
SQL> exit
1. Log in as the user insight and shut down the Sonus Insight server using the following command:
$ sqlplus /nolog
SQL> exit

1. Log in as oracle and enter:
If the Insight database is running, a list of active oracle processes will be displayed.
If the Insight database is not running, no processes will be displayed.
or stop the listener, use the following instructions.
To manually start the listener, login as oracle and use the following command:
$ lsnrctl start
To manually stop the listener, login as oracle and use the following command:

$ lsnrctl stop
$ lsnrctl status
displayed.
Distributed and installed with your Insight database instance, Sonus supplies a series of value added scripts used to
manually backup and restore the Sonus Insight database instance. The scripts make use of database’s export and
import utilities enabling you to manually backup and restore your Insight database. Sonus provides these scripts as
a means to enable the novice user to backup and restore their database. A more sophisticated user may want to
develop a more formal backup and restore strategy.
This section describes the backup and restore of the database only. For a complete system backup and a complete
system restore, see Insight Server Backup and Restore.
Sonus recommends you to backup the Insight database nightly as part of your database backup and restore
strategy.
The required backup scripts and directory hierarchy are installed during an Insight database instance installation or
upgrade. The directories bin, dump and log are created under the Oracle user’s home directory. The location of the
backup and restore scripts is the bin directory. The dump directory holds exported database images and the log
directory stores generated log files.
In the event the required scripts and directory hierarchy do not install, you may manually install the scripts by first
performing a cd to Oracle’s home directory and then untarring the insightBackupFiles.tar file.
You may perform the backup procedure with Sonus Insight running and the database instance in use.
1. Login as user oracle to the system that contains the database instance you wish to backup.
2. Change to the backup and restore bin directory which is located under the oracle user’s home directory
where /export/home/oracle is Oracle’s home directory in this example.
$ cd /export/home/oracle/backup/bin
3. Execute the following script. The export script creates Oracle export files in the data directory and overwrites
any existing export files found at that location.

3.
$ export_manual.sh
What is the password of the database user 'dbimpl'? (default: dbimpl)
Either enter the password of the database, or press enter to accept dbimpl if that is the password of the
database.
5. You will see status information printed to the screen followed by a statement similar to the following:
Export terminated successfully without warnings.
If you did not receive the previous message, refer to the log files found in the log directory to check for any
errors.
Restoring the Insight Database
Perform the following procedure to restore the Insight Database:
CAUTION
You must stop Sonus Insight and not use the database for the first part of the restore procedure. The
restore procedure performs a destructive restore. The process wipes clean the database instance before
restoring the backed up data to the database instance.
1. Shut down any running applications using the database instance you wish to restore. For information on how
to shut down Sonus Insight see the procedure, Stopping the Insight Server.
2. Login as user oracle to the system that contains the database instance you wish to restore.
3. Change to the backup and restore bin directory which is located under Oracle’s home directory where
/export/home/oracle is Oracle’s home directory in this example.
4. Execute the following script. The import script will drop all of your database instance’s tables and import
configuration tables from the archive files in the data directory.
$ cfg_import_manual.sh

5.
database.
6. You will see a series of status information printed to the screen followed by a statement similar to the
following:
Import terminated successfully without warnings.
This is a destructive import where all existing data in the database instance is first dropped before the import
from the export files is performed. The import script drops all sequences and tables and imports the data for
the smaller configuration tables. The process should take less then 20 minutes for a typical size database.
7. The second part of the import is to import the larger Trunk Group and Performance Management tables. As
the time to import these tables may take hours, depending on the size of the data that is to be imported, it
may be desirable for you to re-start Sonus Insight prior to starting this phase of the import. Sonus Insight may
be running and using the database during this phase of the import but information that has not yet been
restored to the database will not be available for use in Sonus Insight until it has been imported. See Starting
the Insight Server for information on starting Sonus Insight.
8. To start the second phase of the import execute the following script.
$ stats_import_manual.sh
following:
Refer to the log files found in the log directory to check for any errors.
Netcool Configuration and Administration Tasks-SA Solaris

On this page:


The annotation /export/home/ems appears throughout the instructions that follow and refers to the
current Sonus Insight installation base directory. The default is /export/home/ems. This is the only
directory that is supported.

This script modifies configuration files, changes process control user settings, and modifies FM logging
parameters.
default.
Under normal circumstances the Netcool processes start and stop when you start or stop the Insight server, see
Insight Server Administration-SA Solaris. If you want to start, stop, or check the status of the Netcool processes
separately from the Insight server, use the following commands.
1. Change the directory to /export/home/ems and start the Netcool processes:

Uninstalling Sonus Insight-SA Solaris
Sonus Insight should not be uninstalled using the commands below unless you intend to permanently remove
Insight from your system. Sonus does not recommend that you uninstall Insight before upgrading Insight.
Perform the following procedure to uninstall Insight:
1. Login to the Insight server as a user with root privileges.

2. Uninstall Sonus Insight:
# cp /export/home/ems/conf/emsUnInstall.sh /tmp
# cd /tmp
# ./emsUnInstall.sh
3. Executing emsUnInstall.sh creates a tar file, /export/home/ems/configFiles.tar. You should

save this file in case you need to revert to the previous installation.
Performing Post-Upgrade Tasks on SA Solaris
This section contains post-installation/upgrade tasks that you may need to perform.
For enabling licensing for devices in EMS, please refer to the “License Manager” chapter in the Insight User
Guide.
Task Purpose
Enabling Disk Mirroring Perform this task to create new disk mirror so that data is in synch
between slave and master disks. The SalesForce upgrade overwrites the
data on disks 0 and 1. Hence, a new disk mirror must be created.
SNMP Management Agent Configuration Perform this task if you are installing SNMP and need to configure the
SNMP Management Agent.
Checking Database Software Shared Memory Perform this task if you upgraded your Sonus application by using the
Settings Sonus Salesforce Customer Portal.
Setting the Location of Core Dump File Perform this task to set the core dump file location.
Clearing Client Browser Cache After a Perform this task on each client after an Insight installation.
Software Upgrade-SA Solaris
Synchronizing with the NTP Server-SA Solaris Perform this task to synchronize with the NTP server.
Online Library Installation or Updates Perform this task to install the documentation.
Clearing Client Browser Cache After a Perform this task on the client after an EMS upgrade.
Software Upgrade-SA Solaris
Netra T5220-Specific NVRAM Settings Perform this task to set the NVRAM variables to the correct values.
Enabling SSH-SA Solaris Perform this task if you are using SSH for communication between the
EMS server and the PSX, SGX, and DSI.

Configuring TCP Wrappers-Aware Perform this task if you need to allow access to TCP Wrappers-aware
Services-SA Solaris services such as SSH and NFS.
Enabling Hardware Traps-SA Solaris Perform this task to enable the hardware traps.
SSL Certificate Installation Procedure Perform this task after an Insight installation if you need to support
HTTPS in a production environment.
Enabling Users to Create cron Jobs-SA Solaris Perform this task after ISO installation if you need to allow users to create
cron jobs.
Enabling Users to Create at Jobs-SA Solaris Perform this task after ISO installation if you need to allow users to create
at jobs.
Performance Data Retention Settings for Perform this task if you are upgrading Insight from a release other than
Upgrades-SA Solaris V07.01.01, V07.01.02, V07.02.01, V07.02.02, V07.02.03 and you want to
change any of the settings from the default of 4 weeks.
Licenses for Enabling Insight API, Insight CLI, Contact your Sonus representative to obtain software licenses.
SMS API, SGX API, Lawful Intercept
Provisioning API, and Traffic Manager-SA
Solaris
Configuring Multiple Network Interfaces-SA Perform this task after an installation if the Insight server uses multiple
Solaris network interfaces.
Configuring IP Network Multipathing for SA Perform this task for non-HA systems after an installation if the Insight
Solaris System server will be using IP network multipathing. This is recommended by
Sonus to protect the EMS from a single-switch failure.
Deploying LNP Adaptor-SA Solaris Perform the task to deploy LNP Adaptor.
Enabling Mailx-SA Solaris Perform this task to enable mailx.
Disabling unused EMS API versions-SA Perform this task to save memory and avoid application failure.
Solaris
Enabling and Disabling HTTP access on the Perform the task to enable and disable HTTP access to EMS server.
EMS Standalone server-SA Solaris
Configuring the Timezone Perform this task to configure the Timezone.
Checking Database Software Shared Memory Settings

If you upgraded Insight by using the installation script from the Sonus Salesforce Customer Portal, perform the
following procedure to check the database shared memory settings and to set them if necessary:

2. Display the /etc/project file and see if the following entry is included:
user.oracle:100::oracle::project.max-sem-ids=(priv,256,
deny);project.max-shm-memory=(priv,4294967295,deny)
3. If the line listed in Step "2" appears in the /etc/project file, this procedure is complete.
If the line listed in Step "2" does not appear in the /etc/project file, continue to Step "4".
4. Add the entry from Step "2" to the /etc/project file (do not include a line break).
5. Reboot the system:

5.
# init 6
Clearing Client Browser Cache After a Software Upgrade-SA Solaris

clear their Web browser's cache to prevent cached pages from the previous version from being temporarily
displayed.
Perform the following procedure to clear the Internet Explorer cache:

2. Select Java.
6. Select Application and Applets check-box, to delete applications and applets. .
The Internet Explorer cache is cleared.
Configuring IP Network Multipathing for SA Solaris System

Overview of IP Multipathing and the configure IPMP Script
Sonus recommends using IP Network Multipathing (IPMP) to provide non-HA systems with uninterrupted access to
a network when a network interface on the system fails or to protect the system from a single-switch failure. This is
achieved by creating a multipath group on the system, which consists of a primary and standby interface (Sonus
recommends that the primary interface and the standby interface be on different cards if possible). If a failure occurs
in the primary interface or its network adapter, the system automatically switches all the network access from the
failed interface and/or adapter to the standby interface.
The configureIPMP script will create an IP multipath group for you, based on the values you enter while running
the script.
Values You Provide
The configureIPMP script will prompt you for the following values. You can use the Table Information needed for
configureIPMP Script to record the values that you will enter when you run the script.
Primary interface — The physical interface that will handle the network access for the multipath group if the

Standby interface — The physical interface that will handle the network access for the multipath group if the
cards if possible.
IPMP group name — The name of the IP multipath group.
Test IP Address for Primary interface — A fully routable address that will be used exclusively for IPMP
testing. Do not use an address that is used for anything else. The test addresses, data addresses, and target
addresses must all be in the same subnet.
Test IP Address for Standby interface — A fully routable address that will be used exclusively for IPMP
Data IP Addresses — The data IP addresses that will be supported by the multipath group. The data
Target IP Addresses — The IP addresses that will be the recipients of and responders to ICMP-echo
requests that are generated by the IPMP daemon. The target addresses are used to determine the state of a
physical interface in the multipath group, and must already exist on the same subnet as the data IP
addresses. You must enter a minimum of two and a maximum of five addresses. IPMP will ping the default
router if you enter less than five target addresses. If you do not want the default router to be pinged, enter five
target addresses.
Network number — The network number that applies to the test IP addresses, the data IP addresses, and
the target IP addresses.
Netmask — The netmask for the IP addresses.
Table 65: Information needed for configureIPMP Script
Standby interface for multipath group
Test IP address for primary interface
Test IP address for standby interface
Data IP addresses
Target IP addresses
Network number
Netmask
Exiting the Script
Creating an IP Multipath Group
Use the following procedure to create an IP multipath group. See "Values You Provide" for a description of the
values you will be entering.
1. On the Insight server, begin the IP multipath script:

# ./configureIPMP
2. Messages appear that give an overview of the script. When prompted, press Enter to continue.
3. Messages appear that explain the conventions used in the script. When prompted, press Enter to continue.
Enter the name of the primary interface, and press Enter.
5. The prompt Standby interface appears, followed by a list of interfaces.
Type the name of the standby interface, and press Enter.
IPMP group name: (Sonus-Mgmt)
Either accept the default value for the multipath group name by pressing Enter, or type a name and press
Enter.
Test IP address for Primary interface
Type the test IP address for the primary interface, and press Enter.
Test IP address for Standby interface
Type the test IP address for the secondary interface, and press Enter.
9. A message appears that states you will enter a set of data addresses. When prompted, press Enter to
continue.
Data IP Address 1
Type the first data IP address that will be supported by the multipath group and press Enter.
Data IP Address 2
If desired, type the second data IP address that will be supported by the multipath group and press Enter. If

you do not want to enter a second address, press Enter.
If you entered a second data IP address, you will be prompted for a third IP address. You will continue to be
prompted for data IP addresses until you press Enter without typing an address.
12. A message appears that states you will enter a set of target IP addresses. When prompted, press Enter to
continue.
Target IP Address 1
Type the first target IP address that will be used by the multipath group and press Enter.
Target IP Address 2
If desired, type the second target IP address that will be used by the multipath group and press Enter. If you
do not want to enter a second address, press Enter.
If you typed a second target IP address, you will be prompted for another IP address. You will continue to be
prompted for target IP addresses until you press Enter without typing an address.
Please provide a network number that applies to all of the addresses you have
provided thus far: (10.6.20.0)
The default value that is displayed will depend on the addresses you have entered so far. Either accept the
default network number for the addresses by pressing Enter, or type the network number and press Enter.
Please provide a netmask that applies to all of the addresses you have
Either accept the default value for the netmask of the addresses by pressing Enter, or type the netmask and
press Enter.
17. All the values that you have entered appear, followed by the prompt:
If the values are what you want, type y and press Enter. Continue to Step "18".
If the values are not what you want, type n and press Enter. Return to Step "4".
18. A message appears, stating that the exact changes that will be made will be displayed.
When prompted, press Enter to continue.
19. A message appears stating either that the network number and netmask combination has been added to
/etc/inet/netmasks, or that the information was already in the file.
20. A message appears showing either the changes that will be made to the hostname.<primaryinterface>

20.
file or the contents of the new file.
21. A message appears showing either the changes that will be made to the hostname.<standbyinterface>
22. Messages appear stating that the file /etc/init.d/ipmp.targets.sonus will be created, and that either unique
MAC addresses are already enabled on the system or they will be enabled.
This is followed by the prompt:
To make all the necessary file changes to create the multipath group, type y and press Enter. Continue to
Step "23".
If you do not want to create the multipath group, type n and press Enter. The script will exit. To run the script
again, return to Step "1".
23. Messages appear listing the files that are being created and stating that the changes are complete. This is
followed by the prompt:
Lastly, please reboot the system for the changes to take effect.
Reboot the system.
Changing the Addresses in a Multipath Group
If you want to change the IP addresses after you configure a multipath group, perform the following procedure.
1. On the Insight server, begin the IP multipath script with the -r option:
# ./configureIPMP -r
The original configuration that existed before you created the multipath group is restored (by restoring the
/etc/*.orig.sonus files).
2. Perform "Creating an IP Multipath Group". Enter the IP addresses that you want to use.
Configuring Multiple Network Interfaces-SA Solaris

When a server has multiple network interfaces, Sonus Insight requires the proper configuration of the /etc/hosts
file. The configuration information in this file allows the user to select the network interface to which a node
connects. During the Node Registration process, the user can select the desired IP Address from the Mgmt Client
IP Address list on the Node Registration screen. The following example of an entry in a /etc/hosts file illustrates
a server, samplehost, having two network interfaces with IP Addresses of 38.45.67.123 and 38.33.54.26.

#
#
127.0.0.1 localhost
38.45.67.123 samplehost samplehost.yourcom.com loghost
Configuring TCP Wrappers-Aware Services-SA Solaris

TCP Wrappers is turned on by default. By default, it blocks access to TCP Wrappers-aware services such as SSH
and NFS.
To configure TCP Wrappers-aware services, create the appropriate rules in the following files:
/etc/hosts.allow
/etc/hosts.deny
In /etc/hosts.allow, change:
sshd: LOCAL
to
sshd: ALL
In /etc/hosts.deny, change:
ALL: ALL
to
#ALL: ALL
Refer to the man page host_access for a description of the rules. To access the man page, enter the
following command:
man -M /usr/sfw/man -s 4 hosts_access
Configuring the Timezone

Perform the following procedure to set the Timezone for EMS System.

2. Edit the file /etc/TIMEZONE, using the vi editor.
3. Change the value of TZ to the new time zone.

3.
Example:
# TZ=US/Pacific
For the complete list of available Time Zones and the specific values, refer /usr/share/lib/zon
einfo.
Caution
It is not recommended to change value of any of the locale values mentioned below to something
other than the default ‘en’ value.
LC_COLLATE=en_US.ISO8859-1
LC_CTYPE=en_US.ISO8859-1
LC_MESSAGES=C
LC_MONETARY=en_US.ISO8859-1
LC_NUMERIC=en_US.ISO8859-1
LC_TIME=en_US.ISO8859-1
4. Reboot the system, using the following command:
# reboot
Deploying LNP Adaptor-SA Solaris

1. Login as insight user and enter the following command to stop Insight:
3. Execute the following command to deploy LNP Application on the Insight server:

3.
# ./deployLNPApplication.sh
4. Enter the following command to restart Insight:
5. For an HA or DR setup, ensure LNP Adaptor is deployed on both the Insight servers. To deploy LNP Adaptor
on other Insight systems, repeat Steps "1" to " 4" on that server.
Disabling unused EMS API versions-SA Solaris

CAUTION
Disable all unused EMS API versions because each version consumes Insight process memory. Too many
versions loaded into memory could result in application failure.
Perform the following procedure to disable the unused EMS APIs:
1. Log on to Insight GUI.

The Users and Roles screen is displayed.
2. Select Insight Administration from the Network Management rollup.
The Insight Administration screen is displayed.
3. From Insight Administration, click the General tab.
The General tab provides access to several categories governing Sonus Insight
configuration.
4. Click Application Management.
The Application Management screen is displayed.
5. From the Devices list, select local host.
From the Components list, select EMS API.
The list of attribute names, values and descriptions are displayed.
6. Select False radio button to disable the used EMS API.
7. Click Apply to save your settings.
Enabling and Disabling HTTP access on the EMS Standalone server-SA

Solaris

1.
2. To enable the access to HTTP, enter the following command:
# cd <BASE_DIR>/conf/security
# ./enableHTTP.sh

Executing /export/home/conf/configHttp -
protocol to http
HTTP port 80
...........................................
............................................
Sonus Insight.
2. To disable the access to HTTP, enter the following command:

2.
# ./disableHTTP.sh

protocol to https
HTTPS port 443
Modifying /export/home/jboss/server/insight/deploy/
Done
Insight.
Enabling Hardware Traps-SA Solaris

Perform the following procedure to enable the hardware traps.
1. As root user, navigate to the following directory:
# cd /export/home/sonusComm/sbin
2. Run the following script:
# ./HwTrapGen.sh

Modifying masfd for t5220...

Modifying snmpd.conf for t5220..
Enabling Mailx-SA Solaris

Perform the following procedure to enable mailx.
Prerequisite
Ensure sendmail packages are downloaded, and installed before you enable it.
To check whether sendmail packages are installed, issue the following command:
# pkginfo | grep Sendmail
The following should be listed:
system SUNWsndmr Sendmail (root)

system SUNWsndmu Sendmail (/usr)
Downloading sendmail Packages
To download the sendmail packages, perform the following:
1. Download Solaris10_Sendmail.tar from the Sonus SalesForce Customer Portal to

/export/home/install/ems:
2. Navigate to /export/home/install/ems:
cd /export/home/install/ems
Enter the following command to extract the Solaris10_Sendmail.tar file:
tar xf Solaris10_Sendmail.tar
3. Navigate to Solaris10_Sendmail:
cd Solaris10_Sendmail

Enter the following command to install the packages:
pkgadd -d . all
Enter y for all the prompts during installation.
Enabling Mailx
To enable mailx, perform the following:
1. As a user with root privileges, modify the etc/hosts file:
# vi /etc/hosts
Append host name with domain name to the entry with host name and IP
Add Mail server IP, Mail server name, Mail server name with domain name
#
#
:: 1localhost
127.0.0.1 localhost
10.54.58.101 emssvt2 loghost <hostname>.<domain-name>
<mail server ip> <mail server name> <mail server name>.<domain-name>
Save and close the hosts file.
cd /etc/mail/
# vi sendmail.cf
Append the mail server name to DS.


# svcadm restart sendmail
# svcs -a | grep sendmail

online 5:31:47 svc:/network/smtp:sendmail
Enabling SSH-SA Solaris

SSH is installed during the installation or upgrade of Solaris 10, but it must be enabled in order to use it. If you want
to use SSH for communication between the Insight server and the PSX, SGX, and DSI servers, you must enable
SSH on the Insight server and on the PSX, SGX, and DSI servers. If you are installing an Insight Application Server
(IAS), you must enable SSH on both the Insight server and the IAS.
This version of SSH includes the following components: SSH Server, SSH client, Secure FTP (SFTP), and Secure
File Copy.
Follow the procedure below to enable SSH on a server:
# cd /etc/ssh

Change:
to
Change:
PermitRootLogin no
to
PermitRootLogin yes
4.

5. Perform "Configuring TCP Wrappers-Aware Services".
# svcadm restart ssh
# svcs -a | grep ssh

online 13:54:00 svc:/network/ssh:default
Enabling Users to Create at Jobs-SA Solaris

1. Ensure that the user does not exist in the /etc/cron.d/at.deny file.
2. Add the user to the /etc/cron.d/at.allow file.
Enabling Users to Create cron Jobs-SA Solaris

1. Ensure that the user does not exist in the /etc/cron.d/cron.deny file.
2. Add the user to the /etc/cron.d/cron.allow file.
Forcing Network Interface Configuration Using Scripts-SA Solaris

Network interfaces capabilities, such as duplex, speed and autonegotiation may be configured by an rc script
located in the /etc/rc2.d directory. The name of the script may vary. It may be S99bge_fdx, or
S99force100fullduplex or a similar name. It is recommended to locate such scripts on your solaris box and
configure the relevant ethernet switch ports (where such NICs are connected) accordingly.
The scripts S99bge_fdx, and S99force100fullduplex in the /etc/rc2.d directory are not part of default
Jumpstart disks, but may be created after the installation by persons who install the boxes.
Example
You may have the following contents in the script to force the network interface speed to 100Mbits, duplex to
full-duplex and turn off auto negotiation:
ndd -set /dev/ce instance 0

ndd -set /dev/ce adv_100T4_cap 0
ndd -set /dev/ce adv_100fdx_cap 1
ndd -set /dev/ce adv_100hdx_cap 0
ndd -set /dev/ce adv_autoneg_cap 0

The above block repeats for each NIC presented in the system (where the ' instance' value increases for each
subsequent NIC.
Licenses for Enabling Insight API, Insight CLI, SMS API, SGX API, Lawful
Intercept Provisioning API, and Traffic Manager-SA Solaris
The modules are:
Insight CLI
Insight API
Insight SMS API
Insight SGX API
If you are upgrading Insight, you do not need to purchase licenses that you have already purchased.
other than the Insight server, you must purchase a license for each instance of an API module you want to use. You
cannot share a license between an API module on the Insight server and an API module on a remote system.
Netra T5220-Specific NVRAM Settings

The following list shows the recommended system NVRAM values that are specific to the Netra T5220. Verify that
these values are correctly set (enter eeprom at the # prompt). Before changing any of these values from the
recommended setting, contact the Sonus TAC.
eeprom ansi-terminal?=true
eeprom auto-boot?=true
eeprom auto-boot-on-error?=true
eeprom boot-command=boot
eeprom boot-device=disk net
eeprom boot-device-index=0
eeprom diag-switch?=false
eeprom error-reset-recovery=boot
eeprom fcode-debug?=false
eeprom keyboard-layout=US-English
eeprom load-base=16384
eeprom local-mac-address?=true
eeprom multipath-boot?=false
eeprom oem-banner?=false
eeprom oem-logo?=false
eeprom pci-mem64?=true
eeprom input-device=virtual-console
eeprom output-device=virtual-console
eeprom screen-#columns=80
eeprom screen-#rows=34

eeprom scsi-initiator-id=7
eeprom security-#badlogins=0
eeprom security-mode=none
eeprom ttya-ignore-cd=true
eeprom ttya-mode=9600,8,n,1,-
eeprom ttya-rts-dtr-off=true
eprom use-nvramrc?=true
eprom verbosity=min
Online Library Installation or Updates

Install the online documentation contained on the Sonus Documentation CD by using the following procedure. You
can also use the following procedure if Sonus provides updates to the documentation.
1. Insert the Sonus Insight Documentation CD into the Insight server CD-ROM drive.
2. Copy the SONSdoc_xxxxxx.tar.Z file to any directory.
3. Decompress the file then untar it using the following command:
# ./docsInstall.sh
The script installs the new online documentation files, which you can then access through the Sonus tab in
the Online Library section of Insight.
Performance Data Retention Settings for Upgrades-SA Solaris

If you are upgrading Insight from V07.xx.xx, then the Data Retention Time for each statistics table will be preserved.
If you are upgrading from any other version , the Data Retention Time for all statistics tables are set to the maximum
value of 4 weeks. To change the Data Retention Time for a statistics table, see the “Data Retention” section in the
Setting the Location of Core Dump File

The dumpadm program specifies the directory that contains core dump files. Sonus recommends that core dump
files be written to the /export/home/<hostname>/ directory, where <hostname> matches the host name of your
system.
This section describes how to check the name of the current dump directory, and how to change the setting to
/export/home/<hostname>/ if necessary.
Checking the Dump Directory Name
To determine the name of the current dump directory, perform the following steps:
1. As a user with root privileges, enter the following command:

1.
dumpadm
2. View the output of the command, which is similar to the following:
Dump content: kernel pages

Dump device: /dev/dsk/c1t0d0s1 (swap)
Savecore directory: /export/home/<dumpdirectory>
Savecore enabled: yes
where <dumpdirectory> is the name of the dump directory.

3. If the actual value for <dumpdirectory> does not match the host name, perform "Changing the Dump
Directory Name".
(To determine the host name of your system, enter the command uname -n.)
Changing the Dump Directory Name
To change the name of the current dump directory, perform the following steps:
1. As a user with root privileges, enter the following command to create the directory:
mkdir /export/home/<hostname>
where <hostname> matches the actual host name of your system.

dumpadm -s /export/home/<hostname>


Savecore directory: /export/home/<hostname>
Verify that the <hostname> value matches the actual host name of your system.
SNMP Management Agent Configuration

The Sun Netra SNMP Management Agent provides an SNMPv2 agent for continuous monitoring of configuration
and faults related to key hardware, such as fans and power supplies and other field replaceable items.

If you are installing SNMP and want to configure the SNMP Agent Software perform the following procedure:
This section contains the following tasks:
Configuring the SNMP Agent Software-After upgrading the SNMP Management Agent, you must configure it.
Manually starting and stopping the SNMP Agent Software-After configuring the SNMP Management Agent,
you must either restart the system or restart the SNMP agent.
Configuring the SNMP Agent Software
You can set specific directives in the SNMP agent’s configuration file. The procedure below provides information
concerning the necessary changes.
1. As the root user, navigate to the following directory:
# cd /etc/opt/SUNWmasf/conf
and open the snmpd.conf file for editing.
The snmpd.conf file contains directives for the agent. The steps that follow detail all necessary
additions/modifications to this file for the proper communication of traps to the Insight EMS system.
For information concerning other directives contained in this file, refer to the SNMP Agent installation
documentation.
2. The default trap community string (used when sending traps) is public. If you use a different community
string, enter a trapcommunity directive in the Trap Destination section of the file. You must place this directive
before any trapsink directives. The correct syntax is:
trapcommunity <your_community_string>
3. In the Trap Destination section of the file enter a trap2sink directive as follows:
trap2sink 127.0.0.1 public 5200
The Netra SNMP Agent is configured to send traps to the SONUS agent. The SONUS agent will forward the
Netra Agent traps to registered EMS or third-party management systems along with product application traps.
4. The generation of an authentication failure standard trap is disabled by default. If you wish to generate an
authentication failure standard trap as a security measure, you must add the following directive to the
configuration file:
authtrapenable 1
5. The installation script sets the listening port to UDP 161. Do not change this value unless there is a known
conflict with another application. If you change the value, Sonus suggests that you change it to 9000. To
change the setting, enter an agentaddress directive. The syntax is:

5.
agentaddress <port>
6. The default agent read community string is public. If you do not wish to allow a default read community string,
comment out the rocommunity directive by adding a # symbol at the beginning of the line. The commented
line would appear:
# rocommunity public
Continue to "Manually Starting and Stopping the SNMP Agent".
Manually Starting and Stopping the SNMP Agent
After upgrading and configuring the agent, you must either restart the system or manually start the agent.
To start the agent manually, use the following command (as root):
To stop the agent, use the following command:
To verify that the agent is running, use the following command:
# ps -ef|fgrep snmpd
The output from the above command showing the snmpd executable.
If you do not see the snmpd process running, check for any error messages in /var/adm/messages.
Synchronizing with the NTP Server-SA Solaris

Your UNIX Administrator should synchronize the Insight server and all network elements in the deployed network to
the same NTP server.
Synchronizing ensures that the timestamps in the Insight logs are consistent with the timestamps on the other
network elements. Failure to do so could also introduce error into certain statistics, most notably the Trunk Group
performance statistics.
synchronized. Conflicting time information from multiple NTP Servers may cause Insight system errors. All
nodes must be set in NTP server. (GSX node, by default, has NTP server set).

Perform the following procedure to configure NTP server in Solaris. All nodes must be configured with NTP server.
By default, GSX has NTP server already configured.

2. Make a copy of ntp.client using the following command:
cp /etc/inet/ntp.client /etc/inet/ntp.conf
3. Using vi editor, edit the /etc/inet/ntp.conf. and replace multicast 224.0.1.1 with your NTP
Server IP address:
multicast 224.0.1.1
with
server <NTP_Server_IP>
4. Restart the NTP service
scvadm disable ntp

scvadm enable ntp
ILOM Configuration on the Netra T5220
Overview
If you are installing the Sonus application on your own Netra T5220 system, you may need to set the Integrated
Lights Out Management (ILOM) boot parameters and upgrade the ILOM firmware.
If you have installed the Sonus application on your own system, read the following:
Overview
Setting the ILOM Boot Configuration
Description of Boot Parameter Values
Setting the ILOM Boot Configuration with the CLI
Setting the ILOM Boot Configuration with the Web Interface
Prerequisite
ILOM Boot Configuration Procedure with the Web Interface
ILOM Web Interface Requirements
Verifying if IP Address is Assigned to the SP Interface
Assigning a Static IP Address to the SP Interface

Ensure that the ILOM boot parameters are properly set by performing either of the following:
Setting the ILOM Boot Configuration with the CLI. This procedure does not require an IP address for the
service processor (SP) interface.
Setting the ILOM Boot Configuration with the Web Interface. This procedure does require an IP address for
the SP interface.
The boot parameter settings are described in Description of Boot Parameter Values.
New JumpStart systems delivered from Sonus have the required ILOM boot parameter settings.
This section describes the ILOM boot configuration values.
To fetch parameter and value settings, cd to parameter folder location and perform ls.

Table 66: ILOM Boot Configuration Values
Location Parameter Setting Description

of the
Parameter
/HOST/diag trigger power-on-reset Runs diagnostics when the system is powered on and
and error-reset when the system resets itself after a fatal error.
/HOST/diag verbosity normal Diagnostics prints a moderate amount of output on the

system console.
/HOST/diag level min Runs the minimum level of diagnostics to verify the
system.
/HOST/diag mode normal Runs diagnostics.
/HOST autorunonerror false The SP powers off the host after the host diagnostics
have discovered a non-fatal POST error.
/HOST autorestart reset Attempts to restart the system when the host leaves the
RUNNING state.
/HOST boottimeout 600 (seconds) Sets the timeout value between the request to boot and
the actual boot to 600 seconds.
/HOST bootrestart reset Resets the boot timeout timer when the timer expires.
/HOST maxibootfail 3 If the host does not reboot after three attempts, it
performs the boot failure recovery setting.
/HOST bootfailrecovery power cycle The host performs a power cycle if the maximum number
of boot failures was reached.
/SYS keyswitch_state normal The system can power itself on and start the boot
process.
/SP/policy HOST_AUTO_POWER_ON disabled When the service processor is booted, the power state of
the host server is set as specified by the host power to
last power state on boot parameter.
/SP/policy HOST_LAST_POWER_STATE enabled When external power is restored after an unexpected

power outage, the host server returns to the power state
it was in before the power outage.
/SP/policy HOST_POWER_ON_DELAY enabled The server waits a random amount of time (between one
to five seconds) before powering on automatically. This
helps to minimize current surges on the main power
source when multiple servers in racks power on after a
power outage.
/SP/policy BACKUP_USER_DATA enabled Backs up the local user database on ILOM (user name,
role, password, and CLI mode information) to the SCC
PROM card.
Perform the following procedure to set the ILOM boot parameters with the CLI:
1. Connect a terminal server to the SER MGT and the NET MGT port on the Netra T5220.
2. Login to –> (ILOM prompt) from serial console.
There are four situations from which you can go to ILOM prompt.
a.

2.
a. If you are in an OS console press #. to get in to ALOM/ILOM prompt.

b. If you are presented with a sc> (ALOM prompt) type logout as follows:
sc> logout
c. If you are presented with a login prompt use root as user name and changeme as password.
The -> prompt appears.
After you get -> prompt you can proceed with Step 4.
If you want switch to ALOM prompt, then proceed with Step 3.
3. Use the following commands to change the prompt from ILOM to ALOM:
Ok> #.
-> set /SP/users/root cli_mode=alom
logout and log back in see the prompt changes from "->" to
"sc>"
sc> poweroff
sc> poweron
sc> console
sc> userclimode root default
logout and log back in see the prompt changes from "sc>" to "-
>"
The command in Step 4 will remove the SP IP address if you have assigned one. You can reassign
the IP address by performing Assigning a Static IP Address to the SP Interface.
-> set /SP reset_to_defaults=all
5. Reset the Service Processor:
-> reset /SP
Are you sure you want to reset SP(y/n)?
6. Enter y.

The connection to the server is broken.
7. Press Enter.
8. At the prompt, log in as root and enter the password (the default password is changeme).
9. After logging in as root, enter the following command to create the admin user:
create /SP/users/admin role=Administrator cli_mode=alom
Creating user...
-> set /HOST/diag level=min

-> set /HOST/diag mode=normal
-> set /HOST boottimeout=600
-> set /HOST bootfailrecovery=powercycle
-> set /SP/policy HOST_LAST_POWER_STATE=enabled
-> set /SP/policy HOST_POWER_ON_DELAY=enabled
11. Enter the following command to connect back to the solaris console.
-> start /SP/console

Are you sure you want to start /SP/console (y/n)? y
Confirm Y to continue.
Serial console started. To stop, type #.
12. Ensure that the boot configuration values are set according to the table ILOM Boot Configuration Values.
Prerequisite

To use the web interface, an IP address must be assigned to the SP interface. See ILOM Web Interface
Requirements.
Perform the following procedure to set the ILOM boot configuration with the Web interface:
1. In your web browser, type the SP IP address in the location bar.

The web interface login page appears.
2. Enter the User Name (default name is root) and the Password (default is changeme), and click the Log In
button.
4. In the Remote Control tab, click on the Diagnostics sub-tab.
5. In the Diagnostics sub-tab, select the following values from the pull-down lists if these values are not already
set:
Trigger: Power On Reset and Error Reset
Verbosity: Normal
Level: Min
Update Mode: Normal
6. Click the Save button.
7. In the Remote Control tab, click on the Host Control sub-tab.
8. In the Host Control sub-tab, select the following values from the pull-down lists if these values are not already
set:
Auto Run On Error: False
Auto Restart Policy: Reset
Boot Timeout: 600
Boot Restart Policy: Reset
Max Boot Fails Allowed: 3
Boot Fail Recovery: Powercycle
10. In the Remote Control tab, click on the Keyswitch sub-tab.
11. In the Keyswitch sub-tab, select Normal from the pull-down list if it is not already set.
13. Click on the Configuration tab.
14. In the Configuration tab, click on the Policy sub-tab.
15. In the Policy sub-tab, select the following values if they are not already set. The Status column indicates the
current setting. To change a setting, click on the radio button and select an item from the Actions pull-down
list.
Auto power-on host on boot: disable
Set host power to last power state on boot: enable
Set to delay host power on: enable
Set to enable backing up of user account info to SCC card: enable
To use the ILOM web interface, an IP address must be assigned to the SP interface.
To determine whether an IP address is assigned to the SP interface, perform Verifying if IP Address is

Assigned to the SP Interface.
To assign a static IP address to the SP interface, perform Assigning a Static IP Address to the SP Interface.

Perform the following procedure to verify if IP Address is Assigned to the SP interface:
1. Connect a terminal server to the SER MGT or the NET MGT port on the Netra T5220.
2. Press Enter.
3. At the prompt, log on as root and enter the password (the default password is changeme).
-> ls /SP/network
If the ipaddress line does not contain a valid IP address, perform Assigning a Static IP Address to
the SP Interface.
If the ipaddress line does contain a valid IP address, you can use the ILOM web interface.
Perform the following procedure, to assign a static IP address to the SP Interface:
2. Press Enter.
-> cd /SP/network
-> set pendingipaddress=<ip_address>
where <ip_address> is the valid static SP IP address.
-> set pendingipnetmask=<netmask>
where <netmask> is the valid static SP IP netmask.

7.
-> set pendingipgateway=<gateway>
where <gateway> is the valid static SP IP gateway.

-> set pendingipdiscovery=static
-> set commitpending=true
10. To verify that the information was entered correctly, enter the following:
-> ls
The IP address information that you entered appears. Verify that this is the correct information.
Migrating Insight Standalone 240 or 440 System to a Netra T5220
This section describes how to migrate an existing Standalone Insight EMS from a Netra 240 or 440 system to a
Netra T5220 system.
For details related to existing licenses post migration, please refer to the “License Manager” chapter in the
Insight User Guide.
This section includes the following"
Task Sequence for Migrating Standalone EMS to a Netra T5220

Exporting Data from the Netra 240/440 Insight System
Importing Data into the Netra T5220
Prerequisite
Passwords
Procedure
Associating the Nodes
Disassociating the Nodes
Upgrading from V09.02.00 to V09.03.00 Software Release
Task Sequence for Migrating Standalone EMS to a Netra T5220

To migrate an existing Standalone Insight EMS from a Netra 240/440 server to a Netra T5220 server, perform the
following tasks in the sequence given:
If you are using Netra 240/440 systems and want to migrate to Netra T5220 then you must migrate using
EMS V09.02.00 release. Migration from 240/440 to 5220 is not supported for any releases after EMS
V09.02.00. Hence, kickstart the Solaris box with 9.2.0 and migrate data to V09.02.00 Release with T5220.
After data is migrated to 9.2.0, you can upgrade from V09.02.00 to V09.03.00 or V09.02.01 and higher
sustaining releases.
1. Kickstart Netra T5220 with EMS V09.02.00 Release. For more details about installing 9.2.0, refer the EMS
V09.02.00 Software Installation and Upgrade Guide.
2. Exporting Data from the Netra 240/440 Insight System (perform on the Netra 240/440 server)
3. Importing Data into the Netra T5220 System with EMS V09.02.00 Release (perform on the Netra T5220
server)
4. Upgrade T5220 System with EMS Software Release V09.02.00 to V09.02.01 or V09.03.00 Release
Export the data from your existing Insight Netra 240/440 system by performing the following procedure, which
generates three files. Later in this chapter you will need to import these files into the new Netra T5220 system.
1. Log on to the Netra 240/440 system as a user with root privileges.

where <yourbackupdirectory> should be replaced with the actual path for the directory in which you
wish to store your backup files. Use a directory that is external to the Insight machine. Use a directory name
that will clearly identify the EMS server that created the backup files. Make a note of the directory path
because you will need it later when migrating data back to the upgraded Insight system.
a. The script returns the following text:
The backup results in the creation of three files in the backup directory.
Table 67: Migration Files when Exporting from EMS Solaris 240 or 440
When Migrating from EMS Solaris 240 or 440 Backup Files generated are
exp_data_manual.dmp

3. Continue to Importing Data into the Netra T5220.
Prerequisite
Before you import data into the Netra T5220, you must have installed Insight EMS V09.02.00. Restore of backup
must be performed on EMS Software Release V09.02.00.
Passwords
The emsMigrate.sh script used in the following procedure gives you the opportunity to use strong passwords,
which must then be entered and must meet a set of restrictions, or to use weak passwords, which are the current
passwords.
Strong passwords have the following restrictions:

– numbers
Procedure
Perform the following procedure to import the data that you earlier saved and exported from your Netra 240/440
system (see "Exporting Data from the Netra 240/440 Insight System"). The Netcool database is also imported.
1. Log on to the Netra T5220 system with EMS Release V09.02.00 as root.
From the backup directory you used for the existing Netra 240/440 EMS server in "Exporting Data from the
Netra 240/440 Insight System", copy the .dmp files to the /export/home/oracle/backup/dump
directory. Also, copy the backupFiles.tar file to the /tmp directory.
If the .dmp files are copied to /export/home/oracle/backup/dump using an unconventional method,
CAUTION

# ./emsMigrate.sh
###############################################################################
You are going to migrate a previous EMS onto this system. Please make sure you
understand what you are doing. Before you proceed, you should also have
already
run manualBackup.sh on the system you want to migrate from, which generated
backupFiles.tar, exp_data_manual.dmp, and exp_strct_manual.dmp. If you are
migrating
from Solaris to Linux then you should have NetcoolBackupFiles.tar.
Place exp_data_manual.dmp and exp_strct_manual.dmp under

/export/home/oracle/backup/dump
and specify the path for backupFiles.tar at the following prompt.
All existing Insight-controlled passwords on this box will be wiped out and
replaced
with the passwords from the restored data.
###############################################################################
Do you wish to continue [y|Y,n|N] ?
4. Enter y to continue.
The following message appears
Stopping running Insight...

Fault Management TrapReceiver have been shut down.
Manage Logs has been shut down.
Call Trace Listener has been shut down.
Insight process monitoring has been stopped.
Stopping Insight running in 26052!
Insight running in 26052 stopped!
completed xslt transform
Done
..............................................................................................
Insight configuration was updated.
[y|Y,n|N] ?

6. Enter y to import.
*****************************************************************************
You have chosen to import User Activity Logs, PM Stats and TrunkGroup Tables.
Please note that this may possibly take a while...
*****************************************************************************
#############################################################################################
Starting importing and upgrading Insight Oracle Database Instance SIDB as user
oracle.
#############################################################################################
stty: : Invalid argument
: : Invalid argument
..............................................................................................
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 -
64bit Production
Modifying /export/home/jboss/server/insight/deploy/jbossweb.sar/server.xml
Done
Completed changing protocol to http. Please restart Sonus Insight.
If you have any IAS registered with the system, then execute the same
procedure on each IAS also by following the procedures provided in the
Insight User Guide.
After completing the migration, you need to perform the following:

a. After migrating data from one EMS server (A) to another EMS server (B), and after registering Insight
node B, you need to unregister Insight node A (which will show up registered as a result of the
migration).
b. Associate the new Insight IP with the nodes. For information, see Associating the Nodes.
c. Disassociate the old Insight IP from the nodes. For information, see Disassociating the Nodes.
1. Login to Insight
2. Navigate to Network Mgmt > Insight Administration
a. SSH Port
b. Login (CLI)
c. Password (CLI)
5. Click on Update button and then click on Discover node.

Perform the following procedure to associate the nodes.
1. You need to associate the node.

2. Perform the following:
a. Navigate to the Insight Administration screen and click the General tab.
b. Select the Managed Device Association link.
c. Enter the Insight IP Address in the IP Address field as shown below.
Figure 343: Associate IP Address Field
d. Click the Associate button.

Figure 344: Associate IP Address Confirmation Screen
e.

e. Click OK.
The operation may take a longer time depending on the number of nodes.
If there are any errors displayed on the final screen at the end of the operation, then the nodes were
not successfully discovered. You need to perform a manual discovery of the nodes after determining
the cause of the error.
For more details, refer to the Node discovery section of the Insight User Guide.
Perform the following procedure to disassociate the node.
1. You need to disassociate the node.

Disassociate all of the nodes with the old EMS IP address to avoid traps being sent from the nodes to the old
EMS IP address
Figure 345: Disassociate IP Address Field
d. Click the Disassociate button.


d.
Figure 346: Disassociate IP Address Confirmation Screen
e. Click OK.
After you have migrated data to EMS Release V09.02.00 with T5220 system, upgrade EMS from V09.02.00 to
V09.03.00 Release. For more information about upgrading, refer the section Upgrading Insight Standalone Using
Sonus Salesforce (Solaris).
Managing Security Settings of Insight SA on Solaris Platform

no longer used in remote agent. For security reasons, these ports are closed from Release V09.02.00 onwards.
Using the configureRPC.sh script you can enable, disable, or see the status of RPC processes. From
release V09.02.00 onwards, the RPC processes will be disabled in case of fresh installation of EMS and IAS and
when EMS is upgraded from a previous versions to V09.02.00 or above. However, if you are upgrading from
Release V09.02.00 to a release higher than V09.02.00 then the previous state of RPC processes will be retained.

To enable, disable or for checking the current state of RPC processes on EMS Standalone Server, refer the
following sections:

Disabling RPC processes on EMS Standalone server
# /export/home/ems/conf/security/configureRPC.sh start
starting the RPC
Starting rpcbind:
# /export/home/ems/conf/security/configureRPC.sh stop
Stopping the RPC
Stopping rpcbind:
# /export/home/ems/conf/security/configureRPC.sh status
To enable, disable or for checking the current state of RPC processes on EMS HA Server, refer the following
sections:

Disabling RPC processes on HA Server
Checking the status of RPC processes on EMS HA Server

To enable RPC process on EMS HA server perform the following commands on primary and secondary servers,
execute the following steps:
1. Enable the RPC processes by perform the following steps on active and standby systems
a. Enable RPC process on active system, by executing the following command:
starting the RPC
Starting rpcbind:
b. Enable RPC process on standby system, by executing the following command:
starting the RPC
Starting rpcbind:

a. Disable RPC process on standby system, by executing the following command:
Stopping the RPC
Stopping rpcbind:
b. Disable RPC process on active system, by executing the following command:
Stopping the RPC
Stopping rpcbind:
# /export/home/ems/conf/security/configureRPC.sh status

1. Change the directory to <BASEDIR>/bin directory by executing the following command:
#cd <BASEDIR>/bin
2. Enable the RPC processes, by executing the configureRPC.sh start command:
#./configureRPC.sh start
starting the RPC
Starting rpcbind:
#cd <BASEDIR>/bin
2. Disable the RPC processes, by executing the configureRPC.sh stop command:
#./configureRPC.sh stop
Stopping the RPC
Stopping rpcbind:
#cd <BASEDIR>/bin
2. Check the status of RPC processes, by executing the configureRPC.sh status command:
#./configureRPC.sh status

The Insight Element Management System Software Upgrade for High Availability (Solaris) provides detailed
instructions to upgrade the Insight EMS software package and other software packages required for its operation.
Table of Contents
Introduction to EMS HA
Insight HA Configurations
Upgrading the Insight Application Server-Solaris HA
Upgrading HA-Introduction
Upgrading Insight High Availability
Managing Insight Account Names and Passwords-HA Solaris
Configuring IPv6 on HA Solaris
Common Administrative Tasks-HA Solaris
Upgrading StorageTek Firmware for HA Setup
Migrating Insight HA 240 or 440 to Netra T5220s
Migrating From Storage Tek RAID to IBM RAID on T5220
Checking Interface Configuration and Routing Table after Configuring HA
ILOM Configuration on the Netra T5220 for HA Setup
Performing Post-Upgrade Tasks on HA Solaris
Managing Security Settings of Insight HA on Solaris Platform
Introduction to EMS HA
This section provides an overview of Insight Element Management System and provides information about hardware
requirements.
Overview on EMS

EMS High Availability
The Insight High Availability (HA) feature provides for the automatic switchover from an active Insight system to a
standby system in the event the active system fails, thereby minimizing any downtime in your management
capabilities.
You may require an HA provisioning infrastructure that is resilient to system failures. Sonus provides such an

infrastructure based on the EMS HA feature.
The EMS HA feature is implemented through the use of a pair of collocated Netra T5220 hardware platforms with a
common IBM DS3524 RAID disk array to store the EMS database. This architecture of Active system, Standby
system, and RAID disk array is conceptually one logical EMS. If the Active system fails, the Standby system
automatically takes over with no manual intervention required. The two systems which comprise the EMS have
redundant LAN links between them that are used for inter-system Keep-Alive communication and monitoring.
The Failover Process
The failover process occurs as follows:
1. A failure in process, connectivity, or resources is detected.

2. If the failure continues, an orderly shutdown of the active EMS system is initiated.
3. The active EMS system stops processes.
4. The active EMS unmounts the shared RAID array.
5. The shared logical interface on the active EMS is disabled.
6. The shared logical interface on the standby EMS system is enabled.
7. The standby EMS system mounts the RAID array.
8. Processes start on the standby EMS system.
The entire failover process takes a minimum of several minutes to complete.
Hardware Requirements for EMS HA configuration
The HA configuration consists of a pair of collocated Netra T5220 hardware platforms with a common IBM DS3524
RAID disk array to store the EMS database. Many factors, from network topology to the nature of user operations,
affect the performance of the system. The Insight application is memory- and I/O-intensive, particularly when
performing large data collections and exporting. If you do not collect performance data extensively or frequently,
then the platform’s ability to support managed devices and users increases. Under heavier loads the performance of
the system will degrade gracefully.
The following table, provides the hardware configuration supported platforms required for (HA) EMS:

Table 68: Hardware Configuration for EMS HA
Platform Configuration
Netra T5220 HA (fourdrive) 4 x 1.2 GHz CPU, 16 GB memory, 4 x 300 GB hard drives,
Quad GigENET Card,
4 x 10/100/1000 Ethernet Ports, Fibre Channel Card
Host Interface Four 8 Gb/s FC ports per controller
Disk Drives 9 x 300 GB 10K 2.5-inch HDD installed in slots 1-9.
Supports 5 and 9 disk configuration.
Sonus recommends 5 disk configuration.
RAID RAID-1+0
Firmware Controller 07.83.27.00
07.77.20.00
IBM DS Storage Manager Host Software Version: 10.83.x5.23 (Solaris)
you do not collect performance data extensively or frequently, then the platform’s ability to support managed devices
StorageTek 2540 Array RAID System Requirements (used with Netra T5220)
When used with the Netra T5220 in a high availability configuration, the optional StorageTek 2540 Array should
meet the requirements shown in StorageTek 2540 RAID Hardware Requirements:

Table 69: StorageTek 2540 RAID Hardware Requirements
Host Four ports, fiber channel 4 GB

Interface
RAID RAID-5; Single Bus; two hot-swap AC or DC power supplies; dual hot-swap RAID controllers; battery
backup module
Firmware 07.35.55.11
root (/) 5GB
var (/) 4GB
opt (/) 5GB
SWAP (/swap) 16GB
(reserved) 0.15GB
(reserved) 0.15GB
Disk Mirroring
Disk 1 <-> Disk 3

Disk 2 <-> Disk 4

UPS Recommendations


Management (ILOM)
Lsof 4.8
Sun Cluster 3.2U2
Appware version 07.77.20.00, 07.83.27.00
Java Server Version 1.7.0_72
Java Client Version 1.7.0_72, 1.8.0_45 (*)
plugin.
Insight HA Configurations
This section describes, how to configure an Insight HA system on two Netra T5220 servers.
Hardware
Setting up an HA configuration on two Netra T5220s involves the following hardware:
Quad GigENET PCI-E card installed on each Netra T5220

2-Port Fiber Channel PCI-E card installed on each Netra T5220
Either one of the following Storage Arrays:
StorageTek 2450 Array with four fiber-optic cables
IBM DS3524 Storage System with four fiber-optic cables.
Restrictions
The following restrictions apply when configuring Insight HA:

The EMS hostname is limited in length to 64 characters. The hostname can only contain lowercase letters
[a-z], digits [0-9], and hyphen[-]. The hostname cannot start with a digit or hyphen, and cannot end with a
hyphen.
Do not configure interfaces that are outside the scope of those defined in the HA procedures. An Insight
system must have the ability to control the source addresses of packets sent to management clients.
Systems such as the GSX inspect the source address of incoming packets to determine the legitimacy of a
request.
The active and standby systems must use the same insight user password.
High Level Task Sequence for Configuring HA

This section and subsequent steps are used if you want to setup HA on existing Solaris Standalone servers. For
example, if you already have to 2 Insight EMS Standalone servers with a prior release earlier than V09.02.00,
upgrade both the EMS Solaris SA servers using Sonus Salesforce upgrade method to V09.03.00. After upgrading
both the servers to V09.03.00, if you want to setup HA between the two Standalone servers, perform the following
steps, to configure both the servers in HA deployment. One of the servers perform the role of primary (active) while
the other servers performs the role of non-primary (standby).
1. Setup and Configure Netra T5220 platforms with RAID Disk Arrays (perform on both the active and standby
EMS systems)
2. Setting Up and Configuring Netra T5220 Systems with StorageTek 2540 Disk Array
3. StorageTek Common Array Manager Software Installation (perform on both the active and standby EMS
systems)
4. Netra T5220 Disk Labeling and File System Creation for the RAID Disk Array (perform on both the active and
standby EMS systems).
5. Private Network Setup.
6. Public Network Setup.
7. The configureHA Script (run configureHA on both the active and standby EMS systems).
8. Checking Interface Configuration and Routing Table for Netra T5220 (verify on both the active and standby
EMS systems).
Setup and Configure Netra T5220 platforms with RAID Disk Arrays
This section describes the setup and hardware configuration for Netra T5220 platforms and RAID disk arrays. The
procedures in this section apply only to Netra 5220s.
Setting Up and Configuring Netra T5220 Systems with IBM DS3524 Storage System
This section describes the setup and hardware configuration for Netra T5220 platforms and IBM DS3524 Storage
system.
The following are the high level/broader steps to setup and configure Netra T5220 Systems with IBM DS3524
Storage System:
Netra T5220 and IBM DS3524 Storage System Connections

IBM DS Storage Manager Software Installation
IBM DS3524 Storage Subsystem Controller IP Address Configuration
IBM DS3524 RAID Disk Array Configuration on Insight EMS Servers

This section describes the procedure for making the physical connections between the IBM DS3524 and the Netra
T5220 systems.
1. Connect one fiber cable to a fiber cable port on Controller A of the DS3524 Storage system. Connect the
other end of the fiber cable to a fiber cable port on the Netra T5220 system that will be the Active system.
See Netra T5220 to DS3524 Storage System Connections figure.
2. Connect a second fiber cable to the other fiber cable port on Controller A of the DS3524 Storage system.
Connect the other end of the fiber cable to a fiber cable port on the Netra T5220 system that will be the
Standby system. See Netra T5220 to DS3524 Storage System Connections figure.
3. Connect a third fiber cable to a fiber cable port on Controller B of the DS3524 Storage system. Connect the
4. Connect a fourth fiber cable to the other fiber cable port on Controller B of the DS3524 Storage system.
Figure 348: Netra T5220 to DS3524 Storage System Connections.
Storage Manager is used to configure, manage, and troubleshoot storage subsystems. It is used primarily to
configure RAID arrays and logical drives, assign logical drives to hosts, replace and rebuild failed disk drives,
expand the size of the arrays and logical drives, and convert from one RAID level to another. Storage Manager
enables troubleshooting and management tasks, such as checking the status of the storage subsystem
components, updating the firmware of the RAID controllers, and managing the storage subsystem.The latest IBM
DS3524 Storage Manager software version is 10.83.x5.23.
The following procedure installs the IBM DS Storage Manager software on a Netra T5220 server. This procedure
should be performed on each of the two Insight servers.

1. Log on to one of the Insight servers (Active/Standby) as root user.
3. Unarchive the SM10.83_Solaris_SMIA-10.83.x5.23.tgz file your system:
# gunzip SM10.83_Solaris_SMIA-10.83.x5.23.tgz
Untar the SM10.83_Solaris_SMIA-10.83.x5.23.tar file:
# tar xvf SM10.83_Solaris_SMIA-10.83.x5.23.tar
# cd Solaris10p83/Solaris
5. Verify the presence of the installer file in the following directory:
# ls SMIA-SOL-10.83.x5.23.bin
6. To run the installation script in non-interactive mode, enter the following:
sh SMIA-SOL-10.83.x5.23.bin -i silent
The installer displays the following:

Preparing to install...
SMIA-SOL-10.83.05.23.bin: !: not found
Extracting the JRE from the installer archive...
Unpacking the JRE...
Extracting the installation resources from the installer
archive...
Configuring the installer for this system's environment...
Launching installer...
Preparing SILENT Mode Installation...
..
.....
......
< text deleted for brevity >
....
.....
Installation Complete.
7. Verify the following files for installation or error logs:
/opt/IBM_DS/IBM_System_Storage_DS_Storage_Manager_10_InstallLog.log
/opt/IBM_DS/IBM\ System\ Storage\ DS\ Storage\ Manager\ 10_InstallErrorLog.log
The IBM DS3524 storage subsystem has two controllers, that are hot-swappable and redundant. The controllers
Two SAS host ports labeled 1 and 2. Each of them is capable of operating at 8Gbps, 4Gbps, and 2Gbps
Four fiber channel host ports labeled FC3,FC4,FC5,FC6. Each of them is capable of operating at 8Gbps,
4Gbps, and 2Gbps
The port on the extreme right is a x4 multilane mini-SAS port for connecting to EXP3524 drive expansion
enclosures

The following procedure assigns an IP address to a DS3524 storage subsystem controller. This procedure should
be performed twice, once for Controller A and once for Controller B.
1. Connect the T5220 server to a simple Hub/Switch after installing DS Storage Manager on both the T5220
servers.
2. Connect Ethernet port 2 on each controller to the same Hub/Switch which is connected to your T5220

2.
servers.
export DISPLAY
echo $DISPLAY
Where <IP Address> is the Ip of the machine where the GUI need to be launched.
5. Login as root to the T5220 server which is connected to the same Hub/Switch and go to the
# ./SMclient
Management window.
discovery.
for the password.
The following are the default port IP addresses in each controller:

12.
192.168.128.101 Port 1
192.168.129.101 Port 2
addresses.
The following procedure configures an IBM DS3524 RAID disk array. This procedure should be performed on one of
the Insight servers and it takes approximately 30 minutes.
1. Log on to one of the Insight servers as root.

# cd /export/home/ems/conf/RAID
3. If an array or disk have been used in another application, the install may require reset to remove any previous
configuration.
To discover the array, enter the following command:
# SMcli -A <IP of Controller A> <IP of Controller B>
For example,
IP of Controller A is 10.54.58.109.
IP of Controller B is 10.54.58.110.
New storage subsystem was discovered at address 10.54.58.109.

SMcli completed successfully.
a. Enter SMcli -i -d if you are discovering the Storage Subsystem for the first time.
For example, the system displays the following:
Unnamed 10.54.58.94 10.54.58.95
b. To rename the unnamed IP, execute the following command:
# SMcli <Unnamed IP> -p <RAID password> -c "set storageSubsystem

userLabel=\" <RAID name>\";"
For example,
# SMcli 10.54.58.94 -p P@ssw0rd -c "set storageSubsystem userLabel=\"
EMSIBMRAID\";"

4. Enter the following command to ensure the RAID name and IP addresses of the controllers are discovered:
# SMcli -i -d
For example, for RAID: EMSIBMRAID
# SMcli -i -d
EMSIBMRAID 10.54.58.109 10.54.58.110
5. Run the configuration script by entering the following:
# ./SONSraidInstall.sh
6. The script detects the RAID the EMS is connected to and prompts for the number of physical disks.
Identifying the connected RAID system .....

EMS is connected to IBM RAID
Enter Num of Disks in RAID(Valid values 5/7/9/11):
The recommended values are only 5 and 9.
7. The script prompts for the physical size of the disk.
Enter Physical Disk size (Valid values 1/2):

1. for 146GB
2. for 300GB
The recommended option is 2. (300 GB). Press Enter after providing the choice.
8. The script prompts for the volume size of the disk.
Enter Volume size (Valid values 1/2):

1. for 136GB
2. for 270GB
The recommended option is 2. Press Enter after providing the choice.
9. Enter the RAID password that you had entered on step 11 of the IBM DS3524 Storage Subsystem Controller
IP Address Configuration section when the following is prompted and press Enter.
Please enter password for IBM Storage Subsystem:
10.

10. Enter the IP address to configure the array when prompted and press Enter:
Enter the IP Address to be used to configure the array.
For example, 10.54.58.109.

11. Enter the device name for the RAID disk array which was displayed on Step 5 when prompted and press
Enter.
Enter the Device Name that is to be used to identify the array (default:
SONSemsarray )
For example, EMSIBMRAID.
The output is displayed as:
EMSIBMRAID
Array Name is EMSIBMRAID
- Getting registered array list
Unregistering array EMSIBMRAID
SMcli completed successfully
....
...
...
Logical drive initialization is under progress. Please re run the script after
some time
#
The above message indicates the steps are complete.

12. Reboot EMS.
# reboot -- -r
Setting Up and Configuring Netra T5220 Systems with StorageTek 2540 Disk Array
This section describes the setup and hardware configuration for Netra T5220 platforms and StorageTek 2540 Disk
Array.
RAID Disk Array Controller IP Address Configuration

Netra T5220 and RAID Disk Array Connections
StorageTek Common Array Manager Software Installation
StorageTek 2540 RAID Disk Array Configuration on Insight EMS Servers
The following procedure assigns an IP address to a RAID disk array controller. This procedure should be performed
twice — once for Controller A and once for Controller B.
1. Power-up the RAID disk array.

2. Use the mini-DIN cable to connect a terminal server to the serial port on one of the RAID disk array
controllers.
3.

3. Send a BREAK signal by pressing Alt-B.
4. When prompted, press S.
5. When prompted, enter the password. If you do not know the default password, contact the Sonus TAC.
Service Interface Main Menu

==============================
1) Display IP Configuration
2) Change IP Configuration
3) Reset Storage Array (SYMbol) Password
Q) Quit Menu
Enter Selection:
Enter 2.
Enable IPv4 (Y/N)?
Enter Y.
Configure using DHCP ? (Y/N):
Enter N.
9. A message similar to the following appears:
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 10.6.9.24
Enter the appropriate IP address value in the New Configuration column. This value is for the controller to
which you are attached. The IP address should be on the same subnet as the “well-known” address that will
be assigned to the multipath group for the active and standby Netra T5220 EMSs.

Subnet Mask 255.255.255.0
Enter the appropriate subnet mask value in the New Configuration column. This value is for the controller to
which you are attached.

11.

Gateway IP Address 10.6.9.1
Enter the appropriate gateway IP address value in the New Configuration column. This value is for the
controller to which you are attached.
12. A message similar to the following appears, which displays the values you entered in Steps 9, 10 and 11 .
The IP Configuration is getting changed to:

IP Address : 10.6.9.24
Subnet Mask : 255.255.255.0
Gateway IP Address : 10.6.9.1
Are you sure that you want to change IP Configuration ? (Y/N):
If the values are correct, enter Y.

If any of the values are not correct, enter N, and return to Step 9.
13. Repeat Steps 2 through 12 or the other RAID disk array controller. (In Step 2 will connect to the serial port of
the other controller.)
This section describes the procedure for making the physical connections between the RAID disk array and the
Netra T5220 systems.
1. Connect one fiber cable to a fiber cable port on Controller A of the RAID disk array. Connect the other end of
the fiber cable to a fiber cable port on the Netra T5220 system that will be the Active system.
2. Connect a second fiber cable to the other fiber cable port on Controller A of the RAID disk array. Connect the
other end of the fiber cable to a fiber cable port on the Netra T5220 system that will be the Standby system.
3. Connect a third fiber cable to a fiber cable port on Controller B of the RAID disk array. Connect the other end
of the fiber cable to a fiber cable port on the Netra T5220 system that will be the Active system.
4. Connect a fourth fiber cable to the other fiber cable port on Controller B of the RAID disk array. Connect the
5. Connect an Ethernet crossover cable directly between the Ethernet port on Controller A of the RAID disk
array and a network interface on one of the Netra T5220 systems. Sonus recommends using interface nxge2
or nxge3.
6. Connect an Ethernet crossover cable directly between the Ethernet port on Controller B of the RAID disk
array and a network interface on the other Netra T5220 system (the one you did not connect in Step 5).

Figure 349: Netra T5220 and RAID Disk Array Connections
The following procedure installs the StorageTek Common Array Manager (CAM) software on a Netra T5220 server.
Before you start the procedure, ensure that you copy the StorageTek2500_CAM.tar.gz file from Salesforce to the
EMS system. This procedure should be performed on each of the two Insight servers.
The CAM software is a command-line interface (CLI) for configuring and managing the RAID disk arrays.
1. Log on to one of the Insight servers as root user.

2. Download the StorageTek2500_CAM.tar.gz file from Salesforce and copy it to the EMS system at the
path /export/home/packages.
4. Unarchive the StorageTek2500_CAM.tar.gz file:

4.
# gzip -dc SONUS_STK2540_CAM_82.tar.gz | tar xf -
# cd storageTek2500_CAM
6. Run the CAM installation script by entering the following:
# ./SONScamInstall.sh
After about 15 minutes, a message appears that states a log file is being written.
7. Repeat Steps 1 to 6 for the other Insight server.
The following procedure configures a StorageTek RAID disk array. This procedure should be run for each of the
RAID disk array controllers (A and B). This procedure should be run on one Insight server for one of the RAID disk
array controllers and run on the other Insight server for the other RAID disk array controller.

configuration. To reset the array, use the following command:
# /opt/SUNWstkcam/bin/sscs reset -l array array <array_name>
5. The script prompts for the number of physical disks:
Enter Num of Disks in RAID (Valid values 5/7/9/11)

Enter a value from the valid values: 5, 7, 9, 11.
Enter Physical Disk size (Valid values 1/2)
Enter a value from 1 and 2 which correspond to 146 GB and 300 GB.
Enter Volume size (Valid values 1/2)
Enter the IP Address to be used to configure the array
8. Enter the IP address for the controller that you connected to this Insight server.
Enter the Device Name that is to be used to identify the array, such as
SONSemsarray.
9. Enter the device name for the RAID disk array. (If this is the second time you are performing this procedure,
enter the same name that you entered the first time.)
When the configuration is complete, a message similar to the following appears:
Done at Tuesday, November 25, 2008 7:50:28 PM EST
10. Repeat Steps 1 through 9 for the other Insight server and RAID disk array controller.
Netra T5220 Disk Labeling and File System Creation for the RAID Disk Array
This section describes the steps for configuring the RAID disk on each Netra T5220 system. Execute the procedures
on each Netra system (the active and standby).
In the example in the steps, c2t2d0s6 will be used for the disk and disk slice on one of the systems. The other
system will use c2t4d0s6.
Active System
This section describes the steps for configuring the RAID disk on the active Netra T5220 system.
1. Log on as root.
2.

2. Display all the drives seen by the operating system by entering:
# format
Example: The following is an example of command output with StorageTek RAID. In following example, 0 to 3
are drives, 4 and 6 are RAID drives, and 5 and 6 are the controllers.

4. c2t2d0 <SUN-LCSM100_F-0735 cyl 34558 alt 2 hd 256 sec 64>
/pci@0/pci@0/pci@9/SUNW,qlc@0/fp@0,0/ssd@w202500a0b85a427e,0
5. c2t2d31 <SUN-UniversalXport-0735 cyl 8 alt 2 hd 64 sec 64>
/pci@0/pci@0/pci@9/SUNW,qlc@0/fp@0,0/
ssd@w202500a0b85a427e,1f
/pci@0/pci@0/pci@9/SUNW,qlc@0,1/fp@0,0/
ssd@w202400a0b85a427e,0
ssd@w202400a0b85a427e,1f
Example: The following is an example of command output with IBM DS 3524 RAID. In the following example,
0 to 3 are drives, 4 and 5 are controllers, and 6 is RAID drive with multipathing enabled.

4. c2t8d31 <IBM-UniversalXport-1060 cyl 8 alt 2 hd 64 sec 64>
/pci@0/pci@0/pci@8/pci@0/pci@9/SUNW,qlc@0/fp@0,0/
ssd@w203c0080e52dfcde,1f
/pci@0/pci@0/pci@8/pci@0/pci@9/SUNW,qlc@0,1/fp@0,0/
ssd@w203d0080e52dfcde,1f
6. c4t60080E50002DFCDE0000158E536939F2d0 <IBM-1814 FAStT-

1060 cyl 53502 alt 2 hd 512 sec 64>
/scsi_vhci/ssd@g60080e50002dfcde0000158e536939f2
Specify disk (enter its number): Specify disk (enter its

number):
3. The available disk selections are displayed, and the following prompt appears:
Specify disk (enter its number):
Enter the number that corresponds to the RAID disk number and not the controller. For StorageTek
RAID, as given in the above example, enter the disk number corresponding to the disk label
SUN-LCSM100_F-0735 and for IBM RAID, enter the disk number corresponding to the disk label
IBM-1814 as given in the above example.
4. If you are using StorageTek RAID, a message similar to the following appears:
selecting c2t2d0
[disk formatted]
Disk not labeled. Label it now?

Enter yes.
5. At the <format> utility prompt, enter verify to ensure that the drive has been labeled and also to display the
disk slices (partition table).
6. At the <format> utility prompt, enter quit to exit the format utility prompt.
7. Create a new UNIX File System (UFS) as follows:
# newfs /dev/rdsk/<partition>
Identify the largest partition that is not labeled backup. In this example, partition6 is the largest partition not
labeled backup. Record the partition number displayed on your system. The disk slice is s6. For the example
shown in Step 4, you would enter:
# newfs /dev/rdsk/c2t2d0s6
8. Mount the disk for testing and verification:

a. Create a mount point (directory) using the following command. The recommended name is:
/export/raid:
# mkdir /export/raid
b. Mount the disk using the following command:
# mount /dev/dsk/<partition> /export/raid
Where <partition> is the designator for your disk and disk slice. The disk was displayed in Step 4. The
disk slice is s6. For the example shown in Step 4, you would enter:
# mount /dev/dsk/c2t2d0s6 /export/raid
c. Record the mount point and device name in System Information Worksheet; you will need it when
running the configureHA script. In our example, we have:
Mount Point: /export/raid
Device Name (also referred to as “Block Device Name”): /dev/dsk/c2t2d0s6
d. Verify that the mounting has succeeded by listing the files in the /export/raid directory:
# ls -ltr /export/raid
Output similar to the following should appear:

total 16
drwx------ 2 root root 8192 Nov 21 11:59
lost+found
e. Verify again by using the command:
# df -h|grep raid
/dev/dsk/c2t2d0s6 134G 64M 132G 1% /export/raid
f. Un-mount after testing is complete using the command:
# umount /export/raid
g. Verify that the un-mounting has succeeded using the command:
# df -h|grep raid
Do not mount the disk and leave it mounted. This occurs automatically when the system
becomes active.
Standby System
This section describes the steps for configuring the RAID disk on the standby Netra system. Because the active
system has already been configured, the steps for labeling and creating a UFS are not required for the standby
system.
1. Log on as root user.


# format
Searching for disks...done
c2t4d31: configured with capacity of 16.00MB
c3t1d31: configured with capacity of 16.00MB AVAILABLE DISK SELECTIONS:
0.c1t0d0 <SUN146G cyl 14087 alt 2 hd 24 sec 848>
4.c2t4d0 <SUN-LCSM100_F-0735 cyl 34558 alt 2 hd 256 sec 64>
ssd@w203400a0b867dc82,0
5.c2t4d31 <SUN-UniversalXport-0735 cyl 8 alt 2 hd 64 sec
64>
ssd@w203400a0b867dc82,1f
ssd@w203300a0b867dc82,0
64>
Example: The following is an example of command output with IBM DS 3524 RAID. In following example, 0 to
3 are drives, 4 and 5 are controllers, and 6 is RAID drive with multipathing enabled.

4. c2t8d31 <IBM-UniversalXport-1060 cyl 8 alt 2 hd 64 sec

64>

64>

1060 cyl 53502 alt 2 hd 512 sec 64>

number):
4. At the format> utility prompt, enter verify to ensure that the drive has been labeled and also to display the
5. At the format> utility prompt, enter quit to exit the format utility prompt.
/export/raid:

Identify the largest partition that is not labeled backup. In this example, partition6 is the largest partition
not labeled backup. Record the partition number displayed on your system. The disk slice is s6. If the
value shown in Step 3 was c2t4d0, you would enter:
c. Record the mount point and device name in Table System Information Worksheet; you will need it
when running the configureHA script. In our example, we have:
total 16
drwx------ 2 root root 8192 Nov 21 11:59 lost+found
# df -h|grep raid

# df -h| grep raid
becomes active.
Private Network Setup

Purpose of Private Network
The primary use for the private network links is the exchange of heartbeat messages between the active and
standby systems. The heartbeat messages allow each system to detect the availability of the other system. The
minimum number of private network connections is 2; however, the more connections that you provide, the more
protection you have against port and card failures. You can have up to 4 private network connections.
For HA to run properly, you must have this private network configured and running properly. If the heartbeat
messages are sent over the public network rather than the private network, under certain conditions the standby
system may attempt a takeover before the active system detects the failure (or while trying to recover from the
failure).
Sonus Recommendations
Sonus recommends at least two private network links between the Active and Standby Netra T5220 systems (you
can establish up to four private network links). At least one of these should be a dedicated hardwired (Ethernet
crossover cable) connection between the Active and Standby systems. You can use any combination of dedicated
hardwired links or non-dedicated links through a hub/switch for the redundant network link(s).
If the redundant network is accomplished using a hub/router (rather than a crossover cable), make sure that the
hub/router's address can be pinged and its interfaces have transmission mode configured to auto-negotiate. These
settings are required to ensure that Keep Alive communications can succeed between the Active and Standby
systems.
For a more robust deployment, the interfaces for each private network link should be on different cards than the
interfaces for the other private network links.
Each private network link should be on a different subnet than the other private network links.
Procedure
The steps below describe the procedure for establishing a private network between the Active and Standby
systems.
1. Connect an Ethernet crossover cable directly between a network interface on the Active and Standby Netra
5220 systems. The Table Private Network Interfaces and IP Addresses shows the recommended interfaces
to use. See the figure Netra T5220 Cross-over Cable Connections. Note that the first and second private
networks are on different cards, as recommended.
2. On the Active and on the Standby Netra systems, use the following steps to assign permanent (persistent
across reboots) IP addresses to the private network interfaces you connected in Step 1. The Table Private

2.
Network Interfaces and IP Addresses shows a sample IP address to use for each interface. Note that the first
private network link is on a different subnet than the second private network link, as required.
a. Create an /etc/hostname.<interface> file for each of the private network interfaces, and in each
file, enter the IP address for the interface.
Example: If one of the private network interfaces is e1000g2 and the IP address is 192.168.5.1, create
the file /etc/hostname.e1000g2 and enter the value 192.168.5.1.
b. Record the value of each IP address in the table System Information Worksheet; you will need these
values when running the configureHA script.
c. In the /etc/netmasks file, enter the network number and netmask for each of the private network
interfaces on the system. Depending on the private network interface IP address, specify the Network
number and subnet mask of the respective private network interface.
Example: If the private network interface number is 192.168.5.2 then enter the network number and
subnet mask in /etc/netmasks file as:
192.168.5.0 255.255.255.0
d. Plumb the IP address by executing the following commands:
(This example considers e1000g2 as the private interface and 255.255.255.0 as the netmask)
# ifconfig e1000g2 plumb

# ifconfig e1000g2 `cat /etc/hostname.e1000g2` netmask 255.255.255.0 up
e. Restart the network services svcadm

f. Test the network by pinging the peer’s private IP address.
Verify that the peer IP addresses are on a private subnet to ensure that packets destined for
the management network are not transmitted through these interfaces.
3. Repeat Steps 1 and 2 to set up the secondary and any other redundant links between the Active and Standby
Netra systems. You can use any combination of dedicated hardwired links or non-dedicated links through a
hub/switch for the redundant network link(s).
Table 73: Private Network Interfaces and IP Addresses
System Item Value
Active Recommended interface for first private network link e1000g2
Peer private IP address example (first network link) 192.168.5.1
Recommended interface for second private network link nxge1
Peer private IP address example (second network link) 192.168.6.1
Standby Recommended interface for first private network link e1000g2

Figure 350: Netra T5220 Cross-over Cable Connections
Public Network Setup

Purpose of Public Network Setup
It is necessary to perform some configuration on each Netra system and collect hardware configuration information
to be used later when you run the configureHA script. The configureHA script will configure the public network and
the multipath group.
The concept of IP Network Multipathing is used for the public network. This concept provides the system with
single-point of failure recovery. A “well-known address” is assigned to a multipath group, which consists of a primary
and secondary interface. If a failure occurs in the primary interface or its network adapter, the system automatically
switches all the network access from the failed interface and/or adapter to the secondary interface. This process
ensures uninterrupted access to the network.

Prerequisite
If not already done, you must set up a management/reachability interface on both the active and standby systems,
and assign each an IP address (refer to the Sun documentation for proper setup procedures). This interface will be
used when a system is in the standby mode to send traps concerning its own operation. The Table Reachability
Interface and IP Address shows the recommended reachability interface and sample IP addresses to use, and
Figure Public Network Connections for Netra T5220 shows the connections. The reachability address must be on
the same subnet as the “well-known” address that will be chosen in "Getting Ready to Configure the Public
Network". Record the value of the reachability IP addresses, you will need these values when running the
configureHA script.
Table 74: Reachability Interface and IP Address
System Item Value
Active Recommended reachability interface e1000g0
Reachability interface IP address example 10.6.9.67
Standby Recommended reachability interface e1000g0
Requirements
The following requirements apply to the public network setup:
The primary and secondary interfaces for the multipath group on a system must be on different cards.
The reachability address and the well-known address must be on the same subnet.
The well-known address must be on a different network than the private network links.
The test addresses must be on the same subnet as the well-known address.
The dummy address must be on the same subnet as the well-known address.
ICMP echo/reply to and from the default router (or hosts identified through static hosts routes) must be
allowed.
Procedure
The procedure below describes the prerequisite steps to be completed concerning the public network before running
the configureHA script.
Activate only those interfaces specified in the procedure below.
1. You must choose the names of the two interfaces used to create the multipath group on each Netra system.
The Table Public Network Interfaces and IP Addresses shows the recommended interfaces to use; note that
the primary and secondary interfaces are on different cards, as required. Record the values, you will need
these values when running the configureHA script.
2. Log on as root.
3. In order to activate these two interfaces on each Netra system, you need to plumb each interface. This
process sets up the streams needed for IP to use the interface. Use the ifconfig command to perform this
task. For example, to plumb interface e1000g1and nxge0, use the following commands:

# ifconfig nxge0 plumb
4. Establish one well-known address on the LAN for assignment to the multipath group for use by the clients.
You only need one well-known address for both Netras on the HA system. The Table Public Network
Interfaces and IP Addresses shows a sample well-known address to use; note that the well-known address is
on a different network than the private network, as required. Also note that the well-known address is on the
same subnet as the reachability address given in Table Reachability Interface and IP Address, as required.
Record the value in the table System Information Worksheet, you will need it when running the
configureHA script.
5. Assign a host-name (such as “EMSHA”) to this well-known address and make an entry in the appropriate
Solaris database on both Netras, for example in the /etc/hosts file or NIS or DNS. Record the value; you will
need it when running the configureHA script.
6. Sonus recommends that you establish two unique test addresses on each Netra system, one for the primary
LAN interface and one for the secondary. These test addresses must be on the same subnet as the
well-known address. These addresses are not for general use. The Table Public Network Interfaces and IP
Addresses, shows sample test addresses to use. Record the values; you will need these values when
running the configureHA script.
Because the active and standby test addresses are not plumbed simultaneously, you can, if you
wish, use the same test address on both systems.
7. Establish one “dummy” address as the back-up/secondary address used for the internal working for the
multipath group. This dummy address must be on the same subnet as the well-known address. This address
is not for general use. You only need one dummy address for both Netras on the HA system. The Table
Public Network Interfaces and IP Addresses, shows a sample well-known address to use. Record the value,
you will need it when running the configureHA script.
During configuration, if a prompt asks for the IP Address, enter the well-known address. If a prompt
asks for the host-name, enter the hostname corresponding to the well-known address. You should
not use the IP address or hostname of an individual Sun system in an HA set-up.
8. Install the cabling from the two interfaces to the appropriate hub/router. The Figure Public Network
Connections for Netra T5220, shows the connections.
Caution
Be sure that the steps in the procedure above are complete for each Netra system.

Table 75: Public Network Interfaces and IP Addresses
System Item Value
Active Recommended primary interface for multipath group e1000g1
Test address example for primary interface for multipath group 10.6.9.80
Recommended secondary interface for multipath group nxge0
Test address example for secondary interface for multipath group 10.6.9.81
Standby Recommended primary interface for multipath group e1000g1
Common to both Netras Well-known address example 10.6.9.84
Dummy address example 10.6.9.85
Hhostname example for well-known address EMSHA

Figure 351: Public Network Connections for Netra T5220
The configureHA Script

This section contains the procedure for running the configureHA script that will configure HA in each Netra system
for the first time.
You only need to follow the procedures in this section when installing Insight (HA) architecture.
Prerequisites
When running the configureHA script on the active and standby Insight systems, the script prompts you for

system information. Table System Information Work Sheet lists the information you will need, and the procedures in
which these values were assigned. You can enter your values into the table and use it as a reference when you run
configureHA.
Before running configureHA, you must have:
Performed the first five items in High Level Task Sequence for Configuring HA
Reset the insight user password. See Changing the “insight” User Password and/or Password Expiration
Behavior. The active and standby systems must use the same insight user password.

Table 76: System Information Worksheet
System Item Value Procedure in which this value was

assigned
Active First peer private IPv4/IPv6 address Private Network Setup
Second peer private IPv4/IPv6 address
OAM (Operations and Management) IP Address Step 8

(Optional)
Primary interface for multipath group Step 14
Test address (IPv4/IPv6/both) for primary interface for Step 18

multipath group
Secondary interface for multipath group Step 15
Test address (IPv4/IPv6/both) for secondary interface for Step 19

multipath group
Reachability interface IPv4/IPv6 address Step 12
RAID mount point Netra T5220 Disk Labeling and File

System Creation for the RAID Disk Array
RAID device name
The fully-qualified path where the orasql directory was To determine the path, login as user ora
created. This is the base directory for oracle, and is most cle and enter the env command. The O
likely: /export/home/oracle RACLE_BASE value displays the path.
Standby First peer private IPv4/IPv6 address Private Network Setup
Primary interface for multipath group Public Network Setup
Test address (IPv4/IPv6/both) for primary interface for

multipath group
Test address (IPv4/IPv6/both) for secondary interface for

multipath group
OAM (Operations and Management) IP Address

(Optional)
Reachability interface IPv4/IPv6 address

RAID device name
Common Well-known (IPv4/IPv6/both) address Public Network Setup

to both
Netras Dummy (IPv4/IPv6/both) address
Hostname for well-known address

Configure HA on EMS systems
The configureHA script configures HA in each Netra system for the first time. The script provides a HA
configuration main menu from which you can choose to configure an active or standby Insight system and perform
other HA configuration operations. The configureHA script collects user information and writes it to the
haConfiguration file in the /export/home/ems/conf/HA directory.
You must run the configureHA script on both the active and standby Insight systems.
Configuring HA on Active System
The following procedure describes how to run configureHA on the active system.
The approximate timeline required to run the configureHA script on the active system is 30 minutes.
1. Log on to Insight as root.

2. Determine whether or not the Insight database is running by logging in as oracle and entering:
a. If the Insight database is running, a list of active oracle processes will be displayed and go to Step 3.
b. If the Insight database is not running, no oracle processes will be displayed. Start the Insight database
by entering the following command and go to Step 3.
$ sqlplus /nolog
SQL> startup
SQL> exit
3. Mount the RAID device using the command:
If necessary replace the c2t2d0s6 in the command line with the designator for your disk. This was established
in the section Netra T5220 Disk Labeling and File System Creation for the RAID Disk Array .
4. Enter the following command to start the configureHA script.
# cd /export/home/ems/conf/HA
# ./configureHA
Insight will be stopped now. Do you want to proceed? (default: yes) [y,n]

Type y and press Enter.
******High Availability Configuration Main Menu ******
Please choose from the following list:
1) Configure system as active or standby
2) Configure OAM IP addresses
3) Input the IP Multipath and Insight Reachability
information.
4) Input Peer IP Addresses for Heartbeat
5) Configure database on the RAID device
6) Configure Netcool on the RAID device
7) Configure SSH and synchronize
8) Configure system as standalone
9) Change IP Addresses
q) quit
Type 1 and press Enter to configure system as active.
Configure as an active or standby system? (default: a) [a,s]:
Press Enter to accept the default. The system then displays the following message:
This system will be configured as an active system.
The steps 8 to 11 are optional and must be executed only if you have an OAM IP address to be
configured. If you do not want to configure an OAM IP address skip steps 8 to 11 and execute the
steps from step 12 onwards.

information.
q) quit
Type 2 and press Enter to enter the OAM IP addresses.

In OAM IP configuration, the OAM IP address uses PSX proxy mode.

OAM stands for Operations And Management. OAM IP address is used by the users to access all
EMS northbound interfaces like GUI, CLI, and API. A user can have two different networks for OAM
and signaling. In this scenario, EMS can act as a proxy for PSX to enable the PSX manager GUI to
talk to PSX. In a standalone EMS deployment with two different networks for OAM and signalling,
the PSX manager GUI connects to the EMS through the EMS OAM IP address, if PSX proxy mode
is enabled. In case of an EMS HA deployment with PSX proxy mode enabled and the user has two
different networks for OAM and signaling, the active EMS and standby EMS have their own
respective OAM IP addresses. In that case, the PSX manager GUI will use the appropriate OAM IP
of the current active server.
Do you want to configure OAM IP address? (default: no) [y,n]:
Type y and press Enter to support OAM IPs.

Please define Active OAM IP address (default: 10.54.6.179):
Type 10.54.6.180 and press Enter.
The OAM IP address is used by PSX to communicate with PSX GUI and EMS acts as a proxy for
PSX.
Defined Active OAM IP is: "10.54.6.180"

Is that correct? (default: y) [y,n]:
Type y and press Enter to update the config file as 10.54.6.180.

information.
q) quit
Type 3 and press Enter to Input the IP Multipath and Insight Reachability information.

13.
IP Multipathing is used to provide network interface resiliency. You

must provide the appropriate information to configure this
functionality.
IP Multipathing uses two physical network
interfaces that are "grouped" together. They share a logical network
interface which uses the "well known" IP Address that all managed
elements and client systems use to access the Insight product.
The
two physical network interfaces that will be used for IP Multipathing
must already be plumbed and attached to the network before continuing.
If they are not plumbed and attached, please do so before continuing.
The
Insight reachability address is used on the standby system to
communicate with any Insight systems that are monitoring it. The
reachability address must be on its own dedicated physical interface.
Following interfaces are currently plumbed and attached to the network:
e1000g0
e1000g1
e1000g2
nxge0
nxge1
Are all the necessary interfaces currently plumbed and attached to the
network? (default: no) [y,n] y

The section will collect information for creating the "Public" IP Multipathing
interface.
Which interface will be the primary? [e1000g0 e1000g1 e1000g2 nxge0 nxeg1]
Type the name of the primary interface for the multipath group, and press Enter.
You would have configured the name of the primary interface for the multipath group while
configuring Public Network Setup.
Which interface will be the secondary? [e1000g0 e1000g1 e1000g2 nxge0 nxeg1]
a. Type the name of the secondary interface for the multipath group and press Enter.
The system would not display the primary interface that have configured in previous step as
an option.
16.

What is the name of the IP Network Multipathing the group. (default:

HA-PUB-GRP):
Press Enter to accept the default.

17. The configureHA script provides the user to configure the HA in IPv4 or IPv4 and IPv6 (dual stack).
Do you intend to configure/change any IPv6 network interfaces this time?

[y|n]:n
Type y and press Enter to configure IPv4 and IPv6 network interfaces.
or
Type n and press Enter to configure only IPv4 network interfaces.
What is the test IPV4 address for the primary LAN interface (default:
10.54.5.32) : 10.54.5.32
What is the test IPV4 address for the primary LAN interface : 10.54.5.32
Type the IP test address for the primary interface for the multipath group, and press Enter.
You would have established the primary interface for the multipath group in Public Network Setup.
What is the test IPV4 address for the secondary LAN interface : 10.54.5.33
Type the IP test address for the secondary interface for the multipath group, and press Enter.
You would have established the secondary interface for the multipath group in Public Network
Setup.
What is the well-known IPV4 address on the LAN (default: 10.54.5.34) :

10.54.5.34

Type the well-known address on the LAN, and press Enter.
You would have established the well known address on the LAN in Public Network Setup.
What is the "dummy" IPV4 address for the secondary interface : 10.54.5.38
Type the dummy address, which you established in Public Network Setup and press Enter.
What is the IPV4 reachability address (default: 10.54.5.31) : 10.54.5.31
Type the reachability address for this system, which you established in Public Network Setup and press
Enter.
23. The system displays the values you entered. The following is an example based on the values given for the
active Netra T5220 system in Public Network Setup.

Primary Interface: "e1000g1"
Secondary Interface: "nxge0"
Multipath Group: "HA-PUB-GRP"
Primary Interface Test IPv4 Address: "10.54.5.32"
Secondary Interface Test IPv4 Address: "10.54.5.33"
Well known IPv4 Address Of The Group: "10.54.5.34"
Dummy IPv4 Address Of The Group: "10.54.5.38"
Reachability IPV4 Address: "10.54.5.31"
Are these values correct? (default: no) [y,n]

24. The system displays the High Availability Configuration Main Menu:
Type 4 and press Enter to configure the input peer IP addresses for the heartbeat.
Please provide the IP Address of the Peer system for Keep Alives.
You can provide up to 4 such addresses.
Peer Keep Alive IP Address 1 (RETURN to stop):
Sonus recommends providing at least two peer private IP addresses for redundancy purposes. Enter the peer
private IP addresses, which you established in Private Network Setup, and press Enter.

[y|n]:

or
Please provide the IPv4 reachability Address of the Peer system for Keep
Alives.
What is the peer's IPv4 reachability address?
Type the reachability address for the other Insight system, which you established in Public Network Setup
and press Enter.
You entered:
Peer Keep Alive IP Address 1: 172.16.5.2
Peer Keep Alive IP Address 3:
Peer's Reachability IP Address: 10.54.5.35
If the information is correct press Enter.

Type 5 and press Enter to configure database on the RAID device.
Enter the requested information for the Oracle User/Installer....

User Name (default: oracle)....
Group Name (default: dba)......
Press Enter to accept the defaults.

You entered...
User Name: "oracle"
Group Name: "dba"
Are the values correct (default:N) [y|Y,n|N] ?

Enter the RAID array's fully-qualified mount point (default: /export/raid)...
Enter the RAID’s mount point, which you established in Netra T5220 Disk Labeling and File System Creation
for the RAID Disk Array and press Enter.

33.
Enter the RAID array's fully-qualified block device name (default:)...
Enter the RAID’s device name, which you established in the section Netra T5220 Disk Labeling and File
System Creation for the RAID Disk Array and press Enter.
Enter the RAID array's fully-qualified character (raw) device name

(default:)...
a. Enter the RAID’s raw device name and press Enter.
The “raw” device name is the same as the device name with the addition of “r” to “dsk” (e.g.
/dev/rdsk/c2t2d0s6).
Enter fully-qualified name of the well-known address of this system...
Enter the well-known IP address, which you established in Public Network Setup, and press Enter.
You entered: 10.6.9.84

Is that correct (default:N) [y|Y,n|N] ?

The system then displays several status messages:
Updating the /var/opt/oracle/oratab, so that this instance is not started at

system startup.
grep "^ *SIDB" /var/opt/oracle/oratab > /dev/null 2>&1
grep -v "^ *SIDB" /var/opt/oracle/oratab > /tmp/tmp10746
field1=`grep "^ *SIDB" /var/opt/oracle/oratab | cut -d ":" -f1`
This script can be used for 2 operations.

1) Move the entire Oracle database from this system to the RAID.
2) Point this system to use the Oracle database already on the RAID.
q) quit
You must decide whether to move the active system database or standby system database to the RAID disk

array. If you choose item 1 for the active system, you must choose item 2 when running the configureHA
procedure on the standby system. You cannot choose the same operation for both systems.
If necessary, you can enter q to return to the main menu.
Press Enter after making your selection.
38. If you chose 1 above, the system displays the following prompt:
Enter the fully-qualified path where the "orasql" directory was

created...default:
Enter the base directory for Oracle and press Enter. For example:
/export/home/oracle
The system then displays a number of status messages that the configureHA script uses to make the
database. The script will backup the database, create a new database and import the backup data into the
new database. The script also turns on archive log and schedules cron jobs for daily backups and cleanup.
mkdir /export/raid/orasql
chown oracle:dba /export/raid/orasql
chmod 775 /export/raid/orasql
Type 6 and press Enter.

1) Move the Netcool files to the RAID.
2) Point this system to use the Netcool files already on the RAID.
If you are configuring an active Insight system, type 1.

If you are configuring a standby Insight system, type 2.
Type 7 and press Enter to configure/test the SSH connection between the systems and to synchronize the
managed node information.
Testing scp
Please enter the root password of the peer:
42. Enter the root password of the peer and press enter.
Check the interfaces on the peer server if the following message appears:

Timeout error. Is device down or IP address xx.xx.xx.xx is invalid or
unreachable?? ssh_expect
43. The system displays the High Availability Configuration Main Menu.
Type 9 and press Enter to change the IP address of system A.
This step will change the IP Address on your system. Do you want to proceed
with this step? (default: yes) [y,n]

Enter the new IP address for this Insight server :

Enter the well-known IP address.
Do you want to notify all registered IAS systems of this new IP address?
(default: no) [y,n]
If there are IASs that were registered to this system and that should be registered to the HA system, type y
and press Enter. Otherwise type n and press Enter.
Changing IP address to '10.6.9.84' in relevant Insight EMS files.

Will be updating Database tables, listener file and init file with the new IP.
Will attempt to restart listener and the database instance.
Will be running netcoolsetup.ksh script to update Netcool related files with
current hostname.
Insight server will be stopped first.

Type q and press Enter to quit and complete the running of the configureHA script.
49. HA Standby server sends sonusHAResourceReleaseFailureNotification alarm when it is not able to
takeover an Active server. Northbound EMS IP and e-mail address must be configured to receive the alarm
or alerts from the HA system.
Perform the following to register Northbound EMS IP and e-mail address:
Update and save the Northbound EMS IP and e-mail address (northBoundEMSIP and emailID) in the
haConfiguration file:

# vi haConfiguration
The e-mail notification is received only if you configure mailx on both the Active and Standby
servers. For information on configuring mailx, see Enabling Mailx-HA Solaris.
50. Perform the steps in Running the haMigrationFiles.sh for running the haMigrationFiles.sh file. For
more information, see Running haMigrateFiles.sh.
51. After you run the configureHA script, you must release resources so that they are available for the
configuration of other Netra systems. Type the following command:
# /export/home/ems/conf/HA/haResources release
Configuring HA on Standby System
Perform the following procedure on the Standby system.
1. Ensure that the database instance is stopped.

Log on to Insight as root.
$ sqlplus /nolog
SQL> startup
SQL> exit

# ./configureHA

Type 1 and press Enter to configure system as standby.
Enter s and the system displays the following message:
This system will be configured as an Standby system.

More details about OAM IP address configuration and PSX Proxy mode are available here.





functionality.
The
The
e1000g0
e1000g1
e1000g2
nxge0
nxge1

interface.
NOTE: You would have configured the name of the primary interface for the multipath group while

an option.

HA-PUB-GRP):


[y|n]:
or
10.54.5.32) : 10.54.5.32

Setup.

10.54.5.34
Enter.




[y|n]:
or
Alives.
and press Enter.
You entered:




31.
You entered...
User Name: "oracle"
Group Name: "dba"


(default:)...



system startup.

q) quit
array.
You must choose a different operation than you chose for the active system. If you chose item 1 for the active
system, you must choose item 2 for the standby system.
Press Enter after making your selection. The system then displays several status messages. If necessary,
you can enter q to return to the main menu.

created...default:
/export/home/oracle
chmod 775 /export/home/oracle/admin/SIDB/udump

mkdir /export/home/oracle/admin/SIDB/arch
chown oracle:dba /export/home/oracle/admin/SIDB/arch
chmod 775 /export/home/oracle/admin/SIDB/arch
rm -rf /tmp/oraclebasevalue

40.

Testing scp



(default: no) [y,n]
47.


current hostname.

52. After you run the configureHA script on the active and standby systems, go to Post-HAconfigure Tasks.

[y|n]:n
or

10.54.5.32) : 10.54.5.32
NOTE: You would have established the secondary interface for the multipath group in Public Network Setup.

10.54.5.34

NOTE: You would have established the well known address on the LAN in Public Network Setup.
Enter.



[y|n]:
or
Alives.
12. Type the reachability address for the other Insight system, which you established in Public Network Setup
and press Enter.
Running haMigrateFiles.sh
Perform the following procedure to run the haMigrateFiles.sh:
1. Log in as user root and enter the following command to start the haMigrateFiles script.

1.
# ./haMigrateFiles.sh
This script creates /export/raid/sonusEms/data and /export/raid/sonusEms/logs folders on

the RAID mounted point and creates the links /export/home/ems/weblogic/sonusEms/dataRaid and
/export/home/ems/weblogic/sonusEms/logsRaid. These links point to
/export/raid/sonusEms/data and /export/raid/sonusEms/logs respectively.
2. The following options are listed:
1. Migrate Inventory, Network Health, Network Fault, Topology and Trunk Group Reports
2. Migrate PM csv files
3. Migrate User Audit Log files
4. Migrate MNP BDD files
5. Migrate All back to Standalone
q. Quit
3. Select 1 from the menu
The following options appear:
1) Move the Report Archives to the RAID.
2) Point this system to use the Report Archives already on the RAID.
q) quit
4. Select 1 from the list of options.
This step moves the existing Report Archives to the RAID and updates the configuration to point to
/export/home/ems/weblogic/sonusEms/dataRaid.
If the script is invoked for standby, select 2.

1) Migrate Inventory, Network Health, Network Fault, Topology and Trunk Group Reports
2) Migrate PM csv files
3) Migrate User Audit Log files
4) Migrate MNP BDD Files
5) Migrate All back to Standalone
q) quit
6. Select 2 from the menu. The following options are listed:
1) Move the PM CSV files to the RAID.
2) Point this system to use the PM CSV files already on the RAID.
q) quit
7. Select 1 from the options. This step moves the existing PM CSV files to the RAID and updates the
configuration to point to /export/home/ems/weblogic/sonusEms/dataRaid.
Creating /export/home/ems/weblogic/sonusEms/dataRaid/pm_archive.
cp -R /export/home/ems/weblogic/sonusEms/data/pm_archive/scp-tmp-dir
/export/home/ems/weblogic/sonusEms/dataRaid/pm_archive.

What is the sqlplus username of SIDB? (default: dbimpl) [dbimpl] :
Enter dbimpl.
What is the sqlplus passwd of SIDB? (default: dbimpl) [dbimpl]::
Enter dbimpl.
q) quit
11. Select 3 from the main menu. The following options are listed:
1) Move the User Audit Log files to the RAID.
2) Point this system to use the User Audit Log files already on the RAID.
q) quit
12. Select 1 from the list of options. This step moves the existing UserAuditLog files to the RAID and updates the
configuration to point to /export/home/ems/weblogic/sonusEms/logsRaid.
Enter dbimpl.
What is the sqlplus passwd of SIDB? (default: dbimpl) [dbimpl]:
Enter dbimpl.
q) quit
1) Move the MNP BDD files to the RAID.

15.
2) Point this system to use the MNP BDD files already on the RAID.
q) quit
16. Select 1 from the list of options. This step moves the existing MNP BDD files for Syniverse to the RAID and
updates the configuration point to
/opt/sonus/ems/weblogic/sonusEms/dataRaid/lnp/final/syniverse. For Telcordia, this step
moves the existing MNP BDD files and updates the configuration point to
/opt/sonus/ems/weblogic/sonusEms/dataRaid/lnp/final/telcordia.
17. Select q from the main menu to generate the High Availability Migration Main Menu.
The following options are listed:
q) quit
18. Select q to quit.
Performing Post-HA Configuration Tasks

After you run the configureHA script on both systems, perform the following tasks:
1. Verify that the interfaces and routing table are configured correctly. See Checking Interface Configuration and
Routing Table for Netra T5220.
2. Enable Multipath for IBM RAIDS. For more details, see MPXIO from T5220 to IBM DS3524 Disk Arrays.
3. First start Insight on the active system and then on the standby system.
4. Register or update the registration of each Insight device (see Chapter 4 of the Insight EMS User Guide).
Checking Interface Configuration and Routing Table for Netra T5220

This section describes how to check the interface configuration and the routing table after you have configured HA.
Example Details
In the example output given in the following procedure, the following assumptions are made:
The output is for a Netra T5220.

e1000g0 is the reachability interface with IP address of 10.10.222.31.
e1000g2 is the interface for the first private network link, and the peer private network address is 192.168.6.1.
nxge1 is the interface for the second private network link, and the peer private network address is
192.168.5.1.
e1000g1 is the primary interface for the multipath group, and the well-known IP address is 10.10.222.30.
nxge0 is the secondary interface for the multipath group, and the dummy IP address is 10.10.222.37.
The name of the multipath group is HA-PUB-GRP.
Procedure
Use the following steps to verify the interface configuration and routing table on each server that is part of an HA setup.
1. Verify the interface addresses and logical address assignment by entering:

1.
ifconfig -a
The output for our example should be:
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index

1
e1000g0: flags=1010843<UP,BROADCAST,RUNNING,MULTICAST,NOXMIT,IPv4> mtu 1500
index 2
inet 10.10.222.31 netmask ffffff00 broadcast
10.10.222.255
ether 0:14:4f:4f:c0:35
nxge0: flags=1000842<BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 29
10.10.222.255
groupname HA-PUB-GRP
ether 0:14:4f:4f:c0:36
nxge0:1:
flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu
1500 index 29
10.10.222.255
inet 192.168.6.1 netmask ffffff00 broadcast 192.168.6.255
ether 0:14:4f:4f:c0:37
10.10.222.255
ether 0:14:4f:42:64:8c
e1000g1:1:
1500 index 28
10.10.222.255
nxge1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 4
ether 0:14:4f:42:64:8e
2. Verify the routing table by entering:
netstat -rn

Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
----------------- -------------- ----- ----- ---- ----------
192.168.5.0 192.168.5.1 U 1 46522 nxge1
192.168.6.0 192.168.6.1 U 1 5585 e1000g2
10.10.222.0 10.10.222.30 U 1 284 e1000g1
10.10.222.0 10.10.222.37 U 1 23 nxge0
10.10.222.0 10.10.222.30 U 1 0 e1000g1:1
10.10.222.0 10.10.222.30 U 1 0 nxge0:1
224.0.0.0 10.10.222.31 U 1 0 e1000g0
default 10.10.222.1 UG 1 174989
127.0.0.1 127.0.0.1 UH 33100429493 lo0
Upgrading the Insight Application Server-Solaris HA
Application Server.
server B.
Before You Begin
Have a system that meets the specifications in Hardware and Software Configuration for EMS HA.
Upgrading an IAS to Solaris HA
Other IAS Procedures-Solaris HA
Upgrading an IAS to Solaris HA



uname -v
Generic_150400-20
the remote system.
started.

Other IAS Procedures-Solaris HA


IAS
following:

Prev IAS version:
Prev Agent version:
Prev JBoss version:
Prev JRE version:
IPv4/IPv6 address.
following:

# cd <IAS_BASE>/bin
# ./enableHTTP.sh

[y,n] y
Stopping IAS...
IAS Server stopped.


# cd <IAS_BASE>/bin
Stopping IAS...
IAS Server stopped.

Upgrading HA-Introduction
This section describes the factors that you must consider before performing an Insight High Availability (HA)
upgrade.
Prerequisites
Insight HA Upgrade Methods
Insight Upgrade Considerations
Creating a Minimal Insight Server
Verifying Netcool Object Server Name
Prerequisites
Before performing an HA upgrade you need to verify the following:
Table 77: Tasks before HA Upgrade
Tasks Description
HA State Ensure that HA is configured correctly and EMS is up and running.
HA state should be either ACTIVE/ACTIVE Or STANDBY/STANDBY
To verify the HA State, enter the following command:
# /export/home/ems/conf/HA/hamgmt getState
Actual State: ACTIVE
Configured State: ACTIVE
System has well known IP.
Raid device is mounted.
Oracle database processes are running.
Oracle Listener is running

Insight Passwords Ensure that the passwords for “insight” system users are same on both the systems.
To verify the passwords, enter the following command:
$ ssh insight@<PEER_REACHABLE_IP>
Connection to the peer should be successful by entering the same passwords on both the systems.
Extraction of the tar Do not manually untar the tar file using the “tar” command.
file
Extract the tar file simultaneously using the following methods on both the systems of HA.
Extract only the commonFunctions.sh utility script

Run the commonFunction.sh script to do the complete extraction
The above procedure is completed in 5 minutes.
Untar the tar file only to /export/home/install/ems
Recording the Ensure that you record the screen output using the script command. This helps you to troubleshoot
Screen output any queries in while performing an upgrade.
NOTE: Run the script command before you start the tar file extraction.
To start session recording, enter the following command:
# script -a /export/home/`hostname`.script.log
# bash
To stop session recording, perform the following:
Type Ctrl-D twice and the following message appears:
# Script done, file is /export/home/emssvt2.script.log
Starting Upgrade All HA upgrade procedure should be performed in sequence.

All commands should be run as root and from the following location:
# cd /export/home/install/ems
Session recording should be in the running state.

You can upgrade Insight HA only using the Sonus SalesForce Customer Portal. For more details, see Upgrading
Insight High Availability.
This section includes the following topics:
Prerequisites
If you do not have a redundant Insight server, in order to maintain management capabilities while upgrading your
system, Sonus recommends that you create a temporary, minimal Insight management platform. The minimal server
has the capability to manage registered nodes, role/user information, and receive traps. The minimal server will run
the same version of Insight that is running on your Insight server (pre-V09.03.00 Insight).
To create the minimal insight platform perform the following:
1. Install the same version of Insight running on your primary server (pre-V09.03.00) to a backup system.
2. Login as root user on the primary Insight server and do the following:
# cd /export/home/ems/weblogic/sonusEms/data/sys
# /bin/tar cf /tmp/nodesUsers.tar Managed*.txt
Record the value generated by the following command:
# /bin/grep tfNotifyRatio SystemConfig.txt

# ftp yourBackupSystem and put /tmp/nodesUser.tar in /tmp
3. Login as root user on the backup system and do the following:
# cd /export/home/ems/weblogic/sonusEms/data/sys
# /bin/tar xf /tmp/nodesUsers.tar
4. Replace all occurrences of the Primary Server IP address with the Secondary Server IP address by entering
the following script.
Note that there is not a line break after upgradeUser’.

for i in `/bin/ls Managed*.txt`
do
/bin/sed 's/OldIpAddress/NewIpAddress/g' $i>$i.new
/bin/mv $i.new $i
done
/bin/egrep -v 'tfNotifyRatio|upgradeNode|upgradeUser'
SystemConfig.txt>afile.txt
/bin/echo "tfNotifyRatio=TheValueFromStep2c">>afile.txt
/bin/echo "upgradeNodeEncryption=true">>afile.txt
/bin/echo "upgradeUserEncryption=true">>afile.txt
/bin/echo "upgradeNodes=true">>afile.txt
/bin/echo "upgradeUsers=true">>afile.txt
/bin/mv afile.txt SystemConfig.txt
5. After running the previous commands, start the system. All users and nodes that existed on the Primary
system now exist on the Backup system.
6. Log on to the system (you must have Administrator privileges) and access the Insight Administrator.
7. Select the General tab and the Managed Device Association category.
8. Enter the IP Address of the newly created Minimal Insight Sever and click the Associate button. This
enables the Minimal Insight Server to receive trap information from the registered nodes.
Before starting EMS upgrade, the Netcool object server name must be SONUSDB by default. The old DB name can
be found at these locations:
Standalone: /export/home/netcool/omnibus/db/{DB_NAME}
HA: /export/raid/Omnibus/db/{DB_Name}
If the object server name is not SONUSDB, it must be updated.
Perform the following the procedure to update the object server name to SONUSDB:
1. Login as user insight and stop the Netcool processes:
2. Execute the following script:
$ /export/home/ems/conf/netcool_rename_db.ksh
3.

3. Enter the old DB name and press ENTER.
4. Enter the new object server name and press ENTER.

5. Start the FM process:
be upgraded:
Caution
When upgrading a system that is running HPC, avoid loss of HPC service by installing and activating the
HPC license (NW-HPC) after you upgrade Insight and before you upgrade PSX. See the Insight EMS
User Guide for details.

For upgrading/downgrading PSX Manager independently of Insight, refer to the

Guide.

Insight CLI, SMS API, SGX API, Lawful Intercept Provisioning API, and Traffic Manager.
10. This guide addresses installation and/or upgrade of Insight only. For instructions on installing/upgrading other
network elements, consult the appropriate guides.

Upgrading Insight High Availability
This section describes how to upgrade an Insight High Availability (HA) system by using Sonus Salesforce
Customer Portal.
Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700
To configure an HA on Netra T5220, see Insight HA Configurations.
This section contains the following sub-sections:
Prerequisites for Insight HA Upgrade

Downloading Insight Upgrade Files
Obtaining the tar files for Upgrade
Upgrade Steps-An Overview
Upgrade procedure for Insight HA
Upgrading PSX Manager GUI on Insight HA Server
Post-Upgrade Tasks
Prerequisites for Insight HA Upgrade

Verify or perform the following tasks prior to upgrading Insight HA.
Table 78: Upgrade Prerequisites
Tasks Description
Netcool Object SONUSDB (Default)

Server Name
Upgrade operation is not supported with the changed netcool object server name. To perform an upgrade, you need to first rollback to
default netcool object server name “SONUSDB”. For changing the netcool object server name, refer Changing Netcool DB Object Server
Name for EMS HA.
Required Space Ensure that there is enough space in /export/home.
For example, 20GB of free space.
Super root access Ensure that you have the following:

and Terminal
Access Super root access on the Solaris system
Terminal access to the HA servers
Private network A minimum of 2 private network connections should be configured. A maximum of 4 private network connections are allowed.
connections

HA State Verify that the HA is configured correctly and EMS is up and running.
The HA state should be either ACTIVE/ACTIVE Or STANDBY/STANDBY.
File Transfer The Solaris OS and Oracle DB related files are transferred to each of the host’s reachable IP only through scp command.
Tar file Extraction Extract the tar files.
Do not use verbose option of tar command (use tar xf instead of tar xvf).
Delete or remove any .tar or tar.gz files that are available after the extraction. This is performed to increase the space in the folder.
emsbootstrap Download the Insight EMS installer file from the Sonus SalesForce Customer Portal and place it at /export/home
Download
For example:
EMS.V09.03.00R000.tar.Z for FTP based upgrade

emsBootstrap-V09.03.00R000.tar for Jumpstart based upgrade.
Uncompress the installer file:
The EMS Installer script automatically untars the file.
Insight Passwords Ensure that the passwords for “insight” system user is same on both the systems.
Recording the Ensure that you record the screen output using the script command. This enables you to troubleshoot any issues while performing an upgrade.
Screen output
Ensure that you run the script command before extracting the tar file.
To start session recording, enter the following:
To stop session recording, type the following:
# Script done, file is /export/home/ems2.script.log
Hardware Ensure that your system meets the minimum hardware requirements.
Requirements
For more details, see Hardware Requirements for EMS HA configuration.
HA Upgrade All HA upgrade procedures should be performed in sequence.

Procedure
All commands should be run from /export/home/install/ems and run as root
Change to the installation staging directory as shown below:
# cd /export/home/install/ems/
Session recorder (script command) should be already running.
CSV files The upgrade script will restore all csv from /export/home/ems/weblogic/sonusEms/data/pm_archive on the configured Active system, if the user enters ' y' to PM
retention in Step 1 - Verifying system configuration - Standby system of the HA Upgrade.
Any csv in the /export/home/ems/weblogic/sonusEms/data/pm_archive on the configured Standby will not be retained. You have to manually tar up and then
back the tar file to a different location, before the upgrade and restore it after upgrade if required.
Any csv written to a non-standard directory other than (/export/home/ems/weblogic/sonusEms/data/pm_archive) will not be retained, even if it is on the Active or
Standby system.
It is recommended to export the PM collection on the RAID directory (/export/home/ems/weblogic/sonusEms/dataRaid/pm_archive), so that the csv files are
always preserved during upgrade.

Insight Upgrade For information on the latest supported upgrade paths, refer to the Release Notes.
Paths
List of Files to be Downloaded before Upgrade
emsBootstrap-V09.03.00R000.tar NA
Prerequisites for Rollback using Disk Mirroring

If you experience any issues in your production network following an upgrade, you can return to the previous version of Insight using disk mirroring.
1. The following mirrors are available where disks 0, 1 are master disks and 2,3 are slave disks.
a. Disk 0 -> Disk 2
b. Disk 1 -> Disk 3
See Enabling Disk Mirroring-HA Solaris for enabling disk mirroring.
2. If you intend to use Disk mirroring as a rollback option, then make sure that mirroring is enabled, and that the mirrors are in sync, using 'metastat -c' command.
Please note that using Disk mirroring as rollback option will require physical access to the system, in case of upgrade failure, to swap the disks
3. After verifying that mirrors are in sync, detach the mirrors, so that mirroring no longer takes place. See Detaching Slave Disk from the Mirror-HA Solaris.
4. Backup the files on RAID
As user root, login to the Active server and make a backup copy of the RAID directories. This will be used in case of rollback:
drwx------ 2 root root 8192 May 24 11:20 lost+found
drwxrwxr-x 3 oracle dba 512 May 24 14:27 orasql
drwxrwxr-x 3 oracle dba 512 May 24 14:27 oradata
drwxr-xr-x 3 insight insight 512 May 24 14:37 Omnibus
drwxr-xr-x 4 root root 512 May 24 15:44 sonusEms
# cd /export/raid
# cp -pR orasql orasql_old
# cp -pR oradata oradata_old
# cp -pR Omnibus Omnibus_old
# cp -pR sonusEms sonusEms_old
Downloading Insight Upgrade Files

Download the following files from the Sonus Salesforce Customer Portal to perform the Insight Upgrade.

Table 79: Files to be Downloaded from Salesforce Customer Portal
Application Software: 1. Login to a shell on the EMS Server as root user.

EMS.V09.03.00R000.tar.Z 2. Download the EMS.V09.03.00R000.tar.Z file from the Sonus Salesforce Customer Portal to /export/home
Solaris Operating System:

Sonus_OS_delta_9.3_Upgrade.tar.gz
For upgrading the Insight to V09.03.00, the Solaris Operating System patch version should be 15
0400-20.

# uname -v
2. Read the output, if the following line appears, the Solaris OS patch has been already installed, and you can skip the
remaining steps.
Generic_150400-20
3. Download the Sonus_OS_delta_9.3_Upgrade.tar.gz file from the Sonus Salesforce Customer Portal to the
/export/home on the target server.
4. Specify the location as /export/home.

Oracle Database: Perform the following steps to verify the Oracle Database version and security patch. If the Database version or security
EMS_SonusDBPackage_solaris-V09.03.00R000.tar patch installed is not the latest, download the Oracle Database file EMS_SonusDBPackage_solaris-V09.03.00R000
.tar from Sonus Salesforce Customer Portal to the EMS server:
For upgrading the Insight to V09.03.00, the Oracle Database version should be 11.2.0.3.0 with
the latest security patch 19271438. Even if the existing database version is 11.2.0.3.0, verify and
ensure that you upgrade to the latest security patch 19271438.

su - oracle
sqlplus -version
If the following line appears, the Oracle Database 11.2.0.3.0 is installed. Even if DB version is 11.2.0.3.0, verify
if the latest security patch has been installed.
su - oracle
b. Enter the following command to verify the latest Security Patch Update (SPU) version is applied on the system:
$ORACLE_HOME/OPatch/opatch lsinv | grep

19271438
If the following line appears, the required Oracle Security Patch has been already installed, and you can skip
the remaining steps.
Patch 19271438 : applied on Wed Oct 01

19:58:21 IST 2014
If the command output does not match the latest Security Patch Update (SPU) version 19271438 then you
need to upgrade the Oracle Database.

a. Download the EMS_SonusDBPackage_solaris-V09.03.00R000.tar file from the Sonus Salesforce Customer
Portal to/export/home/oracle

Solaris Utilities File: Solaris_Utilities_<current_ The Solaris_Utilities_<current_release>.tar is needed while upgrading SNMP software.
release_name>.tar

If the packages are not at least version 1.6.2, then proceed the remaining steps, otherwise no need upgrade the
SNMP software and skip the remaining steps.
3. Download the Solaris_Utilities_<current_release_name>.tar from the Sonus Salesforce Customer Portal to /export/ho
me/tmp.
Obtaining the tar files for Upgrade

This section describes the procedure for upgrading, using the tar files that is obtained from the Sonus Salesforce
Customer portal.
The following are the two tar files used while upgrading Insight.
Installer.tar — The installer file EMS.V09.03.00R000.tar.Z is used while upgrading Insight using the Sonus
Salesforce Customer Portal. The installer file includes the bootstrap file emsBootstrap-V09.03.00R000.tar
Hence, you need not download the bootstrap file separately. The size of the Installer file is over 3GB.
Obtaining Installer file to upgrade Insight using SalesForce Customer Portal
Perform the following procedure both in Active and Standby servers.
The following section describes the procedure for obtaining the Installer file to upgrade Insight using the Sonus
Salesforce Customer Portal.
1. Login to a shell on the EMS server as a root user.

2. To start session recording, enter the following:

# cd /tmp/
# tar xvf /export/home/EMS.V09.03.00R000.tar commonFunctions.sh
# bash commonFunctions.sh extractTar /export/home
Setting up EMS install staging area before upgrade...

Looking for Insight EMS installer tar under /export/home...
Insight EMS INSTALLER tar file...: /export/home/EMS.V09.03.00R000.tar.Z
Installation staging directory...: /export/home/install/ems
Current EMS version...............: V09.03.00R000
Do you want to proceed with extracting the tar file to staging directory?
(default: n) [y|n]: y
4. Enter y, if you want to extract the tar file to the staging directory.
Removing /export/home/install/ems. Please wait...

Moving /export/home/EMS.V09.03.00R000.tar.Z to /export/home/install/ems.
Extracting installer tar file into /export/home/install/ems. Please wait...
Checking if extraction was successful...
Found bootstrap tar /export/home/install/ems/emsBootstrap-V09.03.00R000.tar
Extracting bootstrap tar emsBootstrap-V09.03.00R000.tar into
/export/home/install/ems
Creating backup directory /export/home/backup
Changing file ownership of /export/home/install/ems to root
Making script permissions executable
Making HA script permissions executable
Removing the installer tar file...
Successfully completed extraction of Insight EMS INSTALLER tar file.
Upgrade Steps-An Overview

The List of upgrade steps and approximate time duration table lists an overview of the sequential steps and the
approximate time duration required for performing each step.

Table 80: List of upgrade steps and approximate time duration
Sequence System which owns Well known IP Active Standby Time Duration
No (A-Active, S-Standby) (approximate)
1. A checkSystem 5 minutes
3. A makeStandalone 15 minutes
4. A backupDatabase upgradeSystem 1 hour - Database

Backup
6 hours - Upgrade
using Sonus
SalesForce
5. A pushFiles 15 minutes
6. A restoreDatabase 2 hours
7. * makeStandalone 15 minutes
8. * makeStandby 30 minutes
9. S upgradeSystem 6 hours - Upgrade

using Sonus
SalesForce
10. S pushFiles
11. S restoreDatabase 2 hours
12. S makeActive 30 minutes
13. * failOver 15 minutes
'*' denotes the steps during which the HA EMS server is down.
'A' denotes the steps where the well-known IP is owned by the Active EMS.
'S' denotes the steps where the well-known IP is owned by the Standby EMS.
After performing all the steps listed, you need to perform the Setting up peer root connection on both
the Active and Standby systems.
Upgrade procedure for Insight HA

This section describes how to upgrade Insight HA to V09.03.00 using the following steps.
Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700

Ensure that all commands are run from /export/home/install/ems and run as root.
Perform the following procedure in the sequential order.
1. Step 1 Verifying system configuration - Standby system

2. Step 2 Verifying system configuration - Active system
3. Step 3 Converting the HA Standby System into a Standalone
a. Step 4a Upgrading the Standby (Standalone) System
b. Step 4b Performing the Database backup on the Active System
5. Step 5 Moving or Pushing files from Active to Standby
6. Step 6 Restoring Database on the Standby System
7. Step 7 Converting the HA Active System into a Standalone
8. Step 8 Converting the Standalone Standby to HA Standby
9. Step 9 Upgrading - HA Active System
10. Step 10 Moving or Pushing Files from Standby to Active System
11. Step 11 Restoring Database on the Active system
12. Step 12 Configuring the Active Standalone to HA Active
13. Step 13 Performing a Failover on the Standby system
Step 1 Verifying system configuration - Standby system
To verity the system configuration, you need to run./emsUpgrade.sh checkSystem on the Standby system.
This script checks, collects and displays the system configuration settings. Additionally it also prompts you to enter
the details such as the type of upgrade or status of the PM data and so on.
However, the configuration changes are not performed during this step.
2. Run the following command on the Standby system:
# ./emsUpgrade.sh checkSystem
This step will check, collect and display some system configuration settings.
No configuration changes will be made to the system during this step.
----------------------------------------------------------------------------------------------
EMS can be upgraded via either of the options
below:
1. FTP -In-place upgrade from SalesForce Portal (custom non-EMS
settings are retained)
2. JUMPSTART -USB/HDD upgrade (custom non-EMS settings may be lost)
This option selection can NOT be changed once the upgrade process starts.
Which option do you plan to use? [1|2]:1
4.

4. Enter 1, to upgrade using the Sonus Salesforce Customer Portal.
EMS V09.03.00 Software Release does not support Jumpstart installation and upgrade using USB.
If you want to use EMS V09.03.00 Software for Solaris platform, you must upgrade using Sonus
Salesforce to EMS Software Release V09.03.00. EMS Software Release V09.03.00 only supports
FTP Inplace upgrade from Salesforce portal for Solaris platform.
----------------------------------------------------------------------------------------------
Insight EMS upgrade, it is recommended that Performance Management (PM)
statistics
data NOT be retained and carried forward.
Retaining PM statistics data could significantly increase the upgrade
downtime.
Do you want to retain PM stats related data? (default: n) [y|n]: .......y
5. Enter y, if you want to retain the PM stats related data.
You chose to RETAIN Performance Management statistics data (longer

downtime).
..............................................................................................
if Database Software version will need to be upgraded...
You will need to upgrade the Database Software version from current 11.2.0 to
new version 11.2.0.3 in a later step.
Please
note that as part of that Database Software version upgrade, SKIP the
database export (before upgrade) and import (after upgrade) steps.
Database export and import will be automatically handled by this script and
should NOT be done manually.
Press Enter key to continue...
6. Press Enter key to continue.

Checking HA states...
Getting peer host IP address from config
Peer host's reachable IP address is 10.54.58.101
Checking if peer host 10.54.58.101 can be pinged...
Setting up connection to HA peer. You may be prompted for remote 'insight'
user's password.
.......................................................
......................................................
Testing peer connection, getting remote hostname
Getting some system info...
Following settings are being used for this upgrade:
................................................
This HA (Standby) host ......: ems3
Peer HA (Active) host ......: ems2
PM Statistics Retention .....: YES (Longer upgrade downtime)
Database Software Upgrade ...: No
Do you want to proceed with getting configuration info? (default: n) [y|n]:
y
/export/home/ems
/var
/tmp
7. Enter y, if you want to proceed to obtain the configuration information.


Running preInstall.pl script to get system configuration info...
...........................................................
Starting run of preInstall (Phase: GET_CONFIG) script. Please wait...
*** START: Running preInstall.pl script[GET_CONFIG], at Monday, April1, 2013
4:41:52 PM EDT **
----------------------------------------------------------------------------------------------
preInstall.pl (GET_CONFIG phase) execution on : Monday, April1, 2013
4:41:52 PM EDT
Starting checkInstallation.pl execution on : Monday, April 1, 2013
4:41:53 PM EDT
Creating emsInstall config file...
Creating installation report file...
Please inspect these installation related files before proceeding with

upgrade.
------------------------------------------------------------------
Config settings ........: /export/home/backup/emsInstall.cfg
Installation Report ...: /export/home/backup/preInstallReport.txt
Warnings/errors ........: /export/home/backup/installWarnErrors.txt
------------------------------------------------------------------
Completed preInstall.pl (GET_CONFIG phase) execution on : Wednesday, August

14, 2013 3:58:10 PM IST
----------------------------------------------------------------------------------------------
END: Running preInstall.pl script [GET_CONFIG], at Wednesday, August 14, 2013
3:58:10 PM IST ***
Successfully completed run of preInstall.pl script to collect config
Completed running preInstall (Phase: GET_CONFIG) script, verified backup tar
files.
..............................................................................................
copied install settings file to peer .......
Setting right perms for backup dir
Completed getting system configuration before upgrade.
Caution
Carefully inspect the output of preInstall.pl script run in the previous step. If you see any errors
on the console, do not proceed with the next steps of HA upgrade.
Step 2 Verifying system configuration - Active system
To verify the system configuration on the Active system, follow the same procedure as listed in Step 1 Verifying
system configuration - Standby system.
However, in the Active System, you are not prompted for additional information such as the type of upgrade.

2.
Caution
The steps for running the checksystem script on Active is similar to Standby.
Step 3 Converting the HA Standby System into a Standalone
To convert the HA Standby System into a Standalone, run./emsUpgrade.sh with argument makeStandalone.
This step points to the database on the Standby system from the RAID drive to the local disk. This is performed to
prepare the upgrade of the Standby system.
1. Enter the following command to make the HA Standby system into a Standalone.
# ./emsUpgrade.sh makeStandalone
.........................................
..........................................
Extracted peer host name from config file as 'ems2'
Making HA Standby system 'ems3' into Standalone

...........................
This HA (Standby) host......: ems3
Peer HA (Active) host......: ems2
PM Statistics Retention.....: YES (Longer upgrade downtime)
Database Software Upgrade...: No
........................................................
Do you want to proceed with making this a standalone EMS system? (default: n)
[y|n]: y
3. Enter y, if you want to convert the HA Standby into a Standalone system.

Initiating Insight EMS stop.

................................................
Completed making HA Standby system 'ems3' into Standalone.

Step 4a Upgrading the Standby (Standalone) System
For upgrading using the Sonus Salesforce Customer Portal, upgrade the third party software and continue to Step
4b Performing the Database backup on the Active System. For details, see Upgrading the Third Party Software.
following:

Step 4 Upgrading the Database software
If you are upgrading to Insight V09.03.00, the Solaris Operating System patch version should be 150400-20.
Installing the Solaris Patch may approximately take 90 minutes. Before upgrading the Solaris Patch, you need to
determine the Solaris Patch Level.
1. Determining the Solaris Patch Level

2. Upgrading the Solaris OS Patch
# uname -v


Generic_150400-20
You can copy the Solaris OS patch from the Sonus Salesforce Customer Portal and then perform an upgrade.Copy
Verify that the Sonus_OS_delta_9.3_Upgrade.tar.gz is available at /export/home . For details, see

Downloading Insight Upgrade Files.
Perform the following procedure to upgrade the Solaris OS Patch 150400-20:

a. Log on as insight . (Command: su - insight ).

Done
$ exit
c. Log on as oracle . (Command: su - oracle )

$ sqlplus /nolog
SQL> exit
$ exit

Caution
/bin/ksh.
# reboot -- -s
3. Enter the root user password when the following prompt appears:
5. Perform the following steps to create the OS directory and extact the
commands:
# cd /export/home
space.

8.
# ./upgrade.sh
If you encounter Return Codes 0, 1, 2, 4, or 8 during the patch installation process, you may ignore
them.
# reboot -- -r

15+0 records in
15+0 records out
# uname -v
The following message should appear:
Generic_150400-20
Verify that the Solaris_Utilities_<current_release>.tar is available at /export/home/tmp . For

details, see Downloading Insight Upgrade Files


Netra T5220:

1. Login as root .
# ./install.sh
Netra T5220:


2. If system firmware version is not at 7.4.7 , then perform Upgrading System Firmware
sc> resetsc
# unzip 147309-09.zip

This places the sysfwdownload and the Sun_System_Firmware-7_4_7-Netra_T5220.pkg files in
the /export/home/packages/147309-09 directory.
The 147309-09.zip file is also available from the Sonus Salesforce Customer Portal at: WL9.3
.......... (6%).......... (13%).......... (19%)..........

(26%).......... (33%).......... (39%).......... (46%)..........
(52%).......... (59%).......... (66%).......... (72%)..........
(79%).......... (86%).......... (92%).......... (99%).. (100%)
# shutdown -i0


The system
crown will be shut down in 1 minute

The system
crown will be shut down in 30 seconds

THE SYSTEM

characters.
The character sequence " #. " is usually used.
{0} ok #.
a. login:
b. {0} ok
->
c. {0} ok
sc>
6. After performing step 5, If you are landed in option a.login: (login) prompt:
a. Login using the user name/password as root/changeme .
ORACLESP-0833FM9007 login: root Password: Waiting for daemons to

initialize... Daemons ready Oracle(R) Integrated Lights Out Manager
Version 3.0.12.4.y r77080 Copyright (c) 2010, Oracle and/or its
affiliates. All rights reserved. Warning: password is set to factory
default
b.

-> cd /SP/users/
-> ls

-> cd /SP/users/
-> ls

ALOM.
Creating user...



sc> poweroff

sc> showkeyswitch
following command:

NOTE:
A flashupdate takes about 6 minutes to load a new file. Some commands
are disabled until the file load is complete. The SC will be reset to
complete the upgrade.
ORACLESP-0833FM9007 login: admin Password: Waiting for daemons to

initialize... Daemons ready Oracle Integrated Lights Out Manager Version
3.0.0.0 Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
sc> poweron

sc> console Enter #. to return to ALOM. Done 0:0:0>Network Interface Unit Port
0 Tests ..Done 0:0:0>Network Interface Unit Port 1 Tests ..Done 0:0:0>Extended
Memory Tests....Done ChassisSerialNumber 0833FM9007 A series of events appear
till the console login comes. ................................. activity,
system personnel may provide the | | evidence of such monitoring to law
enforcement officials. |
|-----------------------------------------------------------------| console
login: root password:

1. After you unzip the file 147309.zip , download the Sun_System_Firmware-7_4_7-Netra_T5220.pkg

file to your local system.
The 147309.zip file is also available from the Sonus Salesforce Customer Portal.
2. Log in to the Netra T5220 as root .

4. The web interface login page appears.
5. Enter the User Name (default name is root ) and the Password (default is changeme ), and click the Log
In button.
15. Click browse and navigate to the /export/home/packages/147309-09 directory and select
Sun_System_Firmware-7_4_7-Netra_T5220.pkg .
16. Click the Upload button.
The file is uploaded. This should take about a minute.
17.

b. Click the Start Upgrade button.
19. In the web interface login page, enter the User Name (default name is root ) and the Password (default is
changeme ), and click the Log In button.
21. Verify that the SP Firmware Version displayed is 7.4.7.
24. In the Remote Power Control sub-tab, select Power On from the pull-down list and click the Save button.
Verify that the EMS_SonusDBPackage_solaris-V09.03.00R000.tar is available at /export/home/oracle

. For details, see "Downloading Upgrade Files"
Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700
$ ./sonusEms stop
Perform the following procedure to upgrade the current database 11.2.0.1.0 or 10.2.0.4.0 to Oracle 11.2.0.3 or to
apply latest Security patch, after downloading the Oracle 11.2.0.3 package from the Sonus Salesforce Customer
Portal.
You need not perform a manual database backup if you are upgrading using the preInstall.pl script.
Perform the following procedure to upgrade the database software:
1. Log on as root. (Command: su - root )

2. Navigate to the following location where Insight 09.03.00 package is copied.

The UpgradeOracle.sh script upgrades and brings up the Oracle. The script approximately takes
one hour to complete.

free space:
Step 4b Performing the Database backup on the Active System
You can perform a database backup on Active system using this step. This step backs up the EMS database,
configuration files, and the current state of the Fault Manager. You are recommended not to perform any
configuration changes to EMS from this step till the end of Step 8, because any configuration changes performed
are not retained.
You can perform both Step 4a Upgrading the Standby (Standalone) System and Performing the Database backup
on the Active System (Step 4b) simultaneously.
# ./emsUpgrade.sh backupDatabase

Starting backup of HA Active system 'ems2' database...
.................................
This HA (Active) host......: ems2
Peer HA (Standby) host.....: ems3
.........................................................
..........................................................
Do you want to proceed with backing up the database? (default: n) [y|n]: y
Enter y, if you want to proceed with database backup.

Moving standby tar to /export/home/backup/ems3.backupData.tar

...................................
Completed backup of HA Active system 'ems2' database.
Step 5 Moving or Pushing files from Active to Standby
In this step, certain files are moved or pushed from the Active to Standby system. These files are required later by
the Standby system.
1. Navigate to the following location
# ./emsUpgrade.sh pushFiles

Determining if this is the HA active or standby system
user's password.
Copying key files to peer...
Updating files on peer...
Detected peer's hostname ems3
This step will push certain required tar files to the HA Standby peer system
ems3...
Please make sure that peer system (OS/DB) has been successfully upgraded via
USB/FTP option.
You should run this step after peer system upgrade is complete.
Peer's EMS software will be upgraded automatically in later (restoreDatabase)
step.
Do you want to proceed? (default: n) [y|n]: y
4. Enter y, if you want to proceed with moving the files from Active to Standby.
Checking if backup directory is present on the peer ems3...

Verified that backup directory on peer is correctly setup.
Copying only backupData.tar to HA peer system ems3 [10.54.58.105]. Please
wait...
ems3.backupData.tar...
...................................
Successfully copied backupData.tar to HA peer system ems3
Step 6 Restoring Database on the Standby System
During this step, Insight is upgraded to the latest software version in the Standby system.
It also imports the configuration and the database that was backed up in Step 4b Performing the Database backup
on the Active System.
The local Insight server (Public reachable IP) is started at the end of this step. You can log on to the latest upgraded
system to view and verify the settings. However, this Insight server automatically shuts down at the beginning of the
Step 7 Converting the HA Active System into a Standalone.

2.
# ./emsUpgrade.sh restoreDatabase

Starting database restore of Standalone system ems3.
This step will also upgrade the Insight EMS software to the latest version.
Local Insight EMS server http://ems3 will be started at the end of this step
.Following settings are being used for this upgrade:
.............................
Do you want to proceed with the database restore and Insight EMS upgrade
procedure? (default: n) [y|n]: y
4. Enter y, if you want to restore the database and upgrade Insight.

Checking if Solaris OS has been upgraded to the right version

.....................................................
Completed Insight EMS start.
Completed database restore of Standalone system ems3
For IPv6 configured systems, reboot (reboot -- -r) the system as root user after completing the
database restore.
Step 7 Converting the HA Active System into a Standalone
This step stops the Insight server running on the well-known IP and converts the HA Active system into a
Standalone.
This step is similar to Step 3 Converting the HA Standby System into a Standalone.
As the HA resources are owned by this system, the resources are freed towards the end of this step.

1.
.........................................
..........................................

..................................
...................................................
This step will also STOP the following Insight EMS servers:
1. HA Insight EMS running on Well-known IP
2. Standalone Insight EMS running on Peer
[y|n]: y
4. Enter y, if you want to proceed making the Standby into a Standalone system.

Initiating Insight EMS stop..
................................................
Step 8 Converting the Standalone Standby to HA Standby
This step configures the system as HA Standby, mount the RAID and then moves the database and certain files to
RAID. At the end of this step, the Insight server is started on the well-known IP.

1.
# ./emsUpgrade.sh makeStandby

user's password.
Converting this Standalone system ems3 to HA STANDBY
Insight EMS server http://ems3 will be shut down if running.
Insight EMS server http://10.54.58.104 will be started up.

.........................................................
Do you want to proceed? (default: n) [y|n]:y
4. Enter y, if you want to proceed.

.................................
Step 9 Upgrading - HA Active System
In this step, you need to upgrade the Third Party Software such as the Operating System, Oracle Database, SNMP
and ILOM.
You can perform the similar steps followed in Step 4a Upgrading the Standby (Standalone) System.
Step 10 Moving or Pushing Files from Standby to Active System
In this step, you need to move or push certain files from the Standby to the Active system.

1.
Determining if this is the HA active or standby system.

This is the HA STANDBY system
.....................................................
.....................................................
user's password.
Setting up connection to HA peer. You may be prompted for remote
'insight' user's password.
Testing peer connection, getting remote host name
No files needed to be transferred as this is an FTP based upgrade.
Step 11 Restoring Database on the Active system
This step restores the database on the Active system.
This step is similar to Step 6 Restoring Database on the Standby System.
During this step, Insight is upgraded to the latest software version in the Active system. It also imports the
configuration and the database that was backed up earlier.

3.
....................................................
................................
4. Enter y, if you want to proceed with restoring the database and upgrading Insight.

.....................................................
For IPv6 configured systems, reboot (reboot -- -r) the system as root user after completing
the database restore.
Step 12 Configuring the Active Standalone to HA Active
This step configures the system as HA Active, mounts the RAID, and then moves the database and relevant files to
the RAID.
# ./emsUpgrade.sh makeActive

user's password.
Converting this Standalone system ems2 to HA ACTIVE
Converting this system to HA ACTIVE...

....................................
................................................
Converting this system ems2 to HA ACTIVE with role override option. Please
wait for this to finish...
..................................................
Verified that HA states are as expected (STANDBY/ACTIVE) after Insight EMS
startup.
Step 13 Performing a Failover on the Standby system
During this step, the Standby system currently has the HA resources and EMS running on the well-known IP. This
final step performs a manual failover and brings the HA system to the same state before the upgrade.
# ./emsUpgrade.sh failOver

Checking HA states
...................................................
user's password.
Checking HA states on peer ems2...
Successfully verified that peer ems2 is in correct HA state.
Performing an HA Failover to make this system into HA Standby and peer system
into HA Active.
Starting HA failover. Please wait for this to finish (about 15 mins)...

HA fail over will be requested. Please be patient.
Operation successfully completed.
Re-checking HA states...
Verifying HA states on this system ems3...
Verifying HA states on peer system ems2...
Successfully completed failover.
Upgraded Insight EMS server is now accessible via http://10.54.58.104
a. Login to Insight.
i. SSH Port
ii. Login (CLI)
iii. Password (CLI)
e. Click on Update button and then click on Discover node.
Upgrading PSX Manager GUI on Insight HA Server
This procedure need to be performed on both the active and standby server.


2.
package.
# ./GuiClient.sh


11. You can perform the steps from 12 to 16 on any one of the servers. The configuration will reflect on both the
active and standby servers.
16.


2. If upgrade to V09.03.00R000 failed to complete successfully, perform the following to roll back to old EMS
version.
b. Restore RAID paths on HA Active server. (This step need not be performed on HA Standby server).
i. Shut down Oracle Database server. See Starting and Stopping the Insight Database-HA Solaris
section in Common Administrative Tasks-HA Solaris.
ii. Copy the previously saved RAID sub-directories back:
# cd /export/raid
# rm -R orasql
# rm -R oradata
# rm -R Omnibus
# rm -R sonusEms
# cp -pR orasql_old orasql

# cp -pR oradata_old oradata
# cp -pR Omnibus_old Omnibus
# cp -pR sonusEms_old sonusEms
# rm -R orasql_old
# rm -R oradata_old
# rm -R Omnibus_old
# rm -R sonusEms_old
c. Mount Mirrored disk.

The ‘/’ slice on the mirrored disk need to be mounted locally in order to edit two files on the /etc
path (which lives of ‘/’slice).
' '`s0"


Example:
d. Edit /mnt/etc/vfstab
# cd /mnt/etc
# echo | format


example below.

mount
options
#
no -
no -
yes -
yes -
yes -

slot 0.
e. Edit /mnt/etc/system as root user and delete the following lines if present:


f. Unmount /mnt. As root user, do
# cd
# umount /mnt
g. Physically swap disks and reboot system:

1.) Shutdown the system by running following command as root user:
# init 5

2.) Perform disk swap.
Disks initially at slots 0 and 1 should be inserted back to slots 2 and 3. Otherwise, it will
result in system booting in maintenance mode.
3.) Power up and reboot the system.

Allow the Active server to completely recover before powering on the Standby server.
h. Verify mirror status.

# metastat -c
d201 m 60GB d21

d21 s 60GB c1t1d0s1
d200 m 219GB d20
d106 m 2.0GB d16
d105 m 50GB d15
d15 s 50GB c1t0d0s5
d104 m 202GB d14
d103 m 4.0GB d13
d100 m 5.0GB d10
d101 m 15GB d11
d11 s 15GB c1t0d0s1
d41 s 60GB c1t3d0s1

d35 s 50GB c1t2d0s5
d31 s 15GB c1t2d0s1
i. Dump device need to be set to the original device (e.g. /dev/dsk/c1t0d0s1 for the example above)
j. If you need to restart disk mirroring, clear the metadb and enable the disk mirroring using dmctl. The

j.
# metaclear d41
# metaclear d40
# metaclear d36
# metaclear d35
# metaclear d34
# metaclear d33
# metaclear d30
# metaclear d31
# metaclear -r d201
# metaclear -r d200
# metaclear -r d106
# metaclear -r d105
# metaclear -r d104
# metaclear -r d103
# metaclear -r d100
# metaclear -r d101
Execute the following command to list all the existing metadb state database replicas.
# metadb

Clear all the metadb state database replicas using the following command:
# metadb -df <replica1> <replica2> <replica3> <replica4>
In the above example, replicas are cleared using command:

k. Execute following command to verify that all mirroring configurations are cleared. These commands
# metastat -c
# metadb -i
l. Re-enable disk mirroring by following Enabling Disk Mirroring-HA Solaris.
There will be downtime during the procedure since server will be rebooted as part of
re-enabling disk mirroring.
Post-Upgrade Tasks
After you have upgraded Insight HA to V09.02.00 perform the following:
Setting up peer root connection
Password-less connection for root user needs to be established to the peer HA node after the upgrade
completes.This step can be done while HA EMS server is up and running.
You need to perform this step on both the Active and Standby systems.
Perform the following procedure to set the peer root connection:
1. Run the following command on both the nodes:
# ./configureHA -c setupPeerRootSsh
Setting up 'root' user password-less connection to peer system.

Using the existing key, since key already exists
Please enter the root password of the peer 10.6.20.224 node:

...
Successfully completed setup of 'root' user password-less connection to peer

system.

system.

Managing Insight Account Names and Passwords-HA Solaris
Default Account Names and Passwords-HA Solaris

Changing the Netcool Object Server Name-HA Solaris
Procedures for Changing Passwords-HA Solaris
Default Account Names and Passwords-HA Solaris

upgrades.
root sonus
insight insight
oracle oracle
dbimpl dbimpl
system manager

admin admin
root sonusfm
Changing the Netcool Object Server Name-HA Solaris


Rollback Mechanism

Limitation
“SONUSDB”.
Procedures for Changing Passwords-HA Solaris

restrictions.

Changing Passwords-HA Solaris

The “insight” User Password on the HA Systems
Procedure
Insight Database Password on HA Systems
Procedure

Database sys Password on HA Systems
Procedure
Database system Password on HA Systems
Procedure
Netcool Database User Password for the Insight_Admin_User on HA Systems
Procedure
Netcool Database User Password for the Root User on HA Systems
Procedure
EMS Keystore Password on HA Systems
Procedure
This section describes how to change the insight user password with the changeInsightPassword.sh script. if
you did not use the strong password option when running the configureJumpstart.sh or emsMigrate.sh
script. This changes the insight user password from the previous value.
expiration values.
CAUTION
procedure):

– numbers

The password:
The “insight” User Password on the HA Systems
You must use the same insight user password on all Insight systems that are part of the HA (HA) server. When you
run the changeInsightPassword.sh script on the active HA server, the script will give you the option of
changing the password on all the Insight servers in the system (you will be prompted for the password of the root
user for each server).
Procedure
procedure.
1. Log in as root.
Where:
password.

(Default:Y)

Enter Y.
expiration behavior. Unless you used the -v option in Step 1, the password must meet the restrictions listed in
Password Restrictions.
If you used the -c option in Step 1, continue to Step 6.
If the server is not part of a DR or HA system, continue to Step 9.
Enter Y.

(Default:Y)
(or)
(Default:Y)
(or)
(Default:Y)

procedure):


– numbers
Insight Database Password on HA Systems
When using the changeDbPassword.sh script to change the Insight database password on the active (HA)
system, the database password will also be changed on the standby HA system through the HA monitoring code.
Procedure
(Default:Y)
Enter Y.
Enter the password. Unless you used the -v option in Step 1, the password must meet the restrictions listed in


password when the IAS is up. See Changing the Insight Agent Connection Account Password. If the Insight
% logon admin admin
success
where
% exit

script.

– numbers
Database sys Password on HA Systems
When using the changeSysDbPassword.sh script to change the sys database user password on the active
(HA) system, the database password will also be changed on the standby HA system through the HA monitoring
code.
Procedure

Enter the password. Unless you used the -v option in Step 1, the password must meet the restrictions listed


procedure):

– numbers
Database system Password on HA Systems
When using the changeSystemDbPassword.sh script to change the system database user password on the
active (HA) system, the database password will also be changed on the standby HA system HA monitoring code.
Procedure




– numbers
Netcool Database User Password for the Insight_Admin_User on HA Systems
When using the changeNetcoolDbInsightPassword.sh script to change the password on the active (HA)
system, the password will also be changed on the standby HA system through the HA monitoring code.
Procedure

command:

(Default:Y)
Enter Y.



– numbers
Netcool Database User Password for the Root User on HA Systems
When using the changeNetcoolDbRootPassword.sh script to change the password on the active (HA) system,
the password will also be changed on the standby HA system through the HA monitoring code.
Procedure

(Default:Y)
Enter Y.
This procedure can be used after you obtain your own SSL certificate and import it. See SSL Certificate Installation


– numbers
EMS Keystore Password on HA Systems
When using the changeKeystorePassword.sh script to change the password on the active (HA) system, the
password will also be changed on standby HA system through the HA monitoring code.
Procedure
Enter the password.


5.
Restrictions.

# ./jash
% logon admin admin
success


% exit
passwords.
Configuring IPv6 on HA Solaris

This section contains the procedure to migrate the EMSs in the network from IPv4 to IPv6.
Enable IPv6 on the EMS HA server
Re-register the Device with the IPv6 management address from the EMS Node Registration
Window-HA Solaris
Migrating the StorageTek RAID from IPv4 to IPv6
Prerequisites
Enable IPv6 on the EMS HA server

when the configured Sonus devices are migrated to IPv6. It is not necessary to migrate IPv6 address for private
interfaces. Until the configured Sonus devices are migrated to IPv6, EMS can continue to manage all the configured
The following procedure describes the procedure to enable IPv6 on the EMS HA server.
IPv6 is not supported for private interfaces.
1. Log in as root on both the active and standby systems.

where the <interface name> is the name of the reachability interface used on the HA system. For more
information, see table Reachability Interface and IP Address.
For example, in T5220 the file name will be /etc/hostname6.e1000g0.

3.
For example,
addif FD00:10:6B50:4160::33/60 up

4. Stop EMS on both the Active and Standby systems and then release resources.
Perform the following procedure:
a. Identify the current Active and Standby states of the servers by executing the following commands as
user root:
# /export/home/ems/conf/HA/hamgmt getState | grep Actual
b. Login as user insight and stop insight in Standby (first) and then, on Active by executing the
following commands:
# su - insight
$ exit
c. Login as user root and release the resources in Active (first) and then on Standby by executing the
following command:
5. Plumb the primary and secondary interfaces using the following command:
# ifconfig <interface name> plumb
For more information, see table Public Network Interfaces and IP Addresses.
For example, in T5220 to plumb e1000g1, use the following command:
6. Login as root and run the configureHA script.


7.
# ./configureHA
8. The system displays the HA Configuration Menu.

IP Multipathing is used to provide network interface resiliency. You must

provide the appropriate information to configure this functionality.
IP Multipathing uses two physical network interfaces that are "grouped"
together. They share a logical network interface which uses the "well known"
IP Address that all managed elements and client systems use to access the
Insight product.
The two physical network interfaces that will be used for IP Multipathing must
already be plumbed and attached to the network before continuing. If they are
not plumbed and attached, please do so before continuing.
The Insight reachability address is used on the standby system to communicate
with any Insight systems that are monitoring it. The reachability address must
be on its own dedicated physical interface.
e1000g0
e1000g1
e1000g2
nxge0
nxge1

Which interface will be the primary? [e1000g0 e1000g1 e1000g2 nxge0 nxge2] :
Enter the primary interface.

Which interface will be the secondary? [e1000g0 e1000g2 nxge0 nxge2] :
Enter the secondary interface.

What is the name of the IP Network Multipathing group. (default: HA-PUB-GRP):


[y|n]:
Type y and press Enter to configure IPv6 network interfaces.

What is the test IPv4 address for the primary LAN interface?:
10.54.8.72
fd00:10:6b50:4190::8
What is the test IPv6 address prefix length for the primary
LAN interface? (Default:128):60
What is the test IPv4 address for the secondary LAN

interface?:10.54.8.73
interface?: fd00:10:6b50:4190::9
What is the test IPv6 address prefix length for the secondary
LAN interface? (default:128):60
What is the well-known IPv4 address on the LAN?:10.54.8.78

What is the well-known IPv6 address on the
LAN?:fd00:10:6b50:4190::e
What is the well-known IPv6 address prefix length?
(default:128):60
What is the "dummy" IPv4 address for the secondary

interface?:fd00:10:6b50:4190::d
What is the "dummy" IPv6 address prefix length?
(default:128):60
18.

What is the IPv4 reachability address?:10.54.8.71

What is the IPv6 reachability address?:fd00:10:6b50:4190::7
active Netra T5220 system in Public Network Setup for HA Deployment:

Primary Interface Test IPv6 Address:"fd00:10:6b50:4190::8"
Primary Interface Prefix Length:60"
Secondary Interface Test IPv6 Address:
"fd00:10:6b50:4190::9"
Secondary Interface Prefix Length:"60"
Well known IPv6 Address Of The Group:"fd00:10:6b50:4190::e"
Well known Address Prefix Length: "60"
Dummy IPv6 Address Of The Group:"fd00:10:6b50:4190::d"
Dummy Address Prefix Length:"60"
Reachability IPv4 Address: "10.54.8.71"
Reachability IPv6 Address:"fd00:10:6b50:4190::7"

20. The system displays the HA Configuration Main Menu.

Provide all the requested IP addresses.
You can provide upto 4 such addresses.
Peer Keep Alive IP Address 1 (RETURN to stop) : 172.168.5.2
Peer Keep Alive IP Address 3 (RETURN to stop) :
Please provide the reachability IPv4 Address of the Peer system for Keep
Alives.
What is the peer's reachability address : 10.54.8.74
Alives.
What is the peer's reachability address : fd00:10:6b50:4190::0a
You entered:
Peer's Reachability IPv6 Address: fd00:10:6b50:4190::0a

Type q and press Enter.
22. Start EMS on both the Active and Standby systems by performing the following procedure:
a. Identify the configured Active and Standby states of the servers by executing the following commands
as user root. If the output displays as ACTIVE, then that server is identified as Active server, else
Standby:
# /export/home/ems/conf/HA/hamgmt getState | grep Configured
b. On Active, start Insight as user ‘insight’:
c. On Active, check status of Insight
Expected output: Lists all processes as ‘running’ and current HA state is shown as ACTIVE.
d. On Standby, start Insight as user ‘insight’:
e. On Standby, check status of Insight

e.
Expected output: Lists all processes as ‘running’ and current HA state is shown as STANDBY.
f. Exit from user insight.
$ exit
23. Open EMS GUI on active system and re-register devices with the IPv6 management client IP Address. See
Re-register the Device with the IPv6 management address from the EMS Node Registration Window .
Node Registration Window-HA Solaris


4. Click Register.
Migrating the StorageTek RAID from IPv4 to IPv6

Once the hosts connected to RAID are migrated to IPv6, you can migrate the RAID to IPv6. Follow the procedure
below to migrate the StoregTek RAID to IPv6.
2.

controllers.
3. Press uppercase S within five seconds when the following prompt appears:
Press within 5 seconds: <S> for Service Interface <BREAK> for baud rate
4. Enter the password within 60 seconds at the following prompt:
Enter Password to access Service Interface (60 sec timeout):

==============================
Q) Quit Menu
Enter Selection:2
Enter 2.
7. Once you select option 2, skip the IPv4 part as it is already configured:
Enable IPv4? (Y/N) : y

Configure using DHCP ? (Y/N): n
Press '.' to clear the field;
Press '-' to return to the previous field;
IP Address if0 : 10.54.72.73
Subnet Mask if0 : 255.255.255.0
Gateway IP Address if0 : 10.54.72.1
NO change in IP Configuration
Enable IPv6 (Y/N)?
Enter Y.
9. Enter N for Stateless Address Autoconfiguration:

Configure using Stateless Address Autoconfiguration? (Y/N): n
10. Accept default value for IPv6 Local Address:
IPv6 Local Addr if0 :

Current Configuration :::
New Configuration :::1
11. Enter the IPv6 address of the server as the IPv6 Routable Address:
IPv6 Routable Addr if0 :

Current Configuration :fd00:10:6b50:4150::49
New Configuration :
12. Enter the IPv6 address of the router (gateway) as the IPv6 Routable Address:
IPv6 Router Addr if0 :

New Configuration
13. Verify if the IP addresses are correct.

Local IPv6 Address : ::1
Routable IPv6 Address : fd00:10:6b50:4150::49
14. Enter 'y' after verifying the IPs. Following confirmation message will be displayed:
Network Configuration successfully changed.
15. Reset the controller for changes to take effect:
Reboot to have the settings take effect? (Y/N) y
16. Register the storageTek array using IPv6 address from the host connected to RAID using the following
command:

16.
sscs add -i <IPv6 address> registeredarray
17. Repeat Steps 1 through 15 for the other RAID disk array controller.
Common Administrative Tasks-HA Solaris
Disk Mirroring-HA Solaris

Insight Server Administration-HA Solaris
Insight Server Backup and Restore-HA Solaris
Insight Server Database Administration-HA Solaris
Starting and Stopping the Insight Database-HA Solaris
Netcool Configuration-HA Solaris
HA Insight Server Administration
Account Management-HA Solaris
Uninstalling Sonus Insight-HA Solaris
Changing Netcool DB Object Server Name for Solaris HA
Disk Mirroring-HA Solaris

Disk Mirroring Overview-HA Solaris
Disk 1 Disk 3
Disk 2 Disk 4

mirrored disks

d10 d30 d100
d11 d31 d101
d13 d33 d103
d14 d34 d104
d15 d35 d105
d16 d36 d106
d20 d40 d200
d21 d41 d201

Enabling Disk Mirroring-HA Solaris
mirroring for Insight is supported on Netra T5220 four-disk systems. Before performing an upgrade, ensure that disk
mirroring is enabled.
Caution
# pkginfo SONSdmems

Ensure that the drive definitions are of format c1t*d*. If not, edit the /opt/SONSdmems/config/p
mirroring.

Enter yes.

5.

Enter yes.

The
Enter yes.
the next step.

Enter yes.
# metastat -c

d106 m 2.0GB d16 d36 (resync-0%)
d105 m 50GB d15 d35 (resync-0%)
d15 s 50GB c1t0d0s5
d35 s 50GB c1t2d0s5
d104 m 59GB d14 d34 (resync-0%)
d14 s 59GB c1t0d0s4
d34 s 59GB c1t2d0s4
d103 m 4.0GB d13 d33 (resync-0%)
d100 m 5.0GB d10 d30 (resync-0%)
d101 m 15GB d11 d31 (resync-0%)
d11 s 15GB c1t0d0s1
d31 s 15GB c1t2d0s1

Enter yes.

Enter yes.

An
Enter yes.

the next step.

Enter yes.
# metastat -c
d200 m 76GB d20 d40 (resync-0%)

d20 s 76GB c1t1d0s0
d40 s 76GB c1t3d0s0
d106 m 2.0GB d16 d36 (resync-0%)
d105 m 50GB d15 d35 (resync-0%)
d15 s 50GB c1t0d0s5
d35 s 50GB c1t2d0s5
d104 m 59GB d14 d34 (resync-0%)
d14 s 59GB c1t0d0s4
d34 s 59GB c1t2d0s4
d201 m 60GB d21 d41 (resync-0%)
d21 s 60GB c1t1d0s1
d41 s 60GB c1t3d0s1
d103 m 4.0GB d13 d33 (resync-3%)
d100 m 5.0GB d10 d30 (resync-2%)
d101 m 15GB d11 d31 (resync-0%)
d11 s 15GB c1t0d0s1
d31 s 15GB c1t2d0s1
17. Enable disk mirror error reporting (through email). See Customizing Health Monitoring-SA Solaris.

18.
Health-SA Solaris.
Checking the Status of Mirrors-HA Solaris
metastat -c
metadb -i
Disabling Disk Mirrors-HA Solaris
Caution


5.



# metastat -c
Suspending Disk Mirrors-HA Solaris
Resuming Disk Mirrors-HA Solaris

Detaching Slave Disk from the Mirror-HA Solaris
This procedure should be done on both servers of the EMS HA pair that are getting upgraded.
$ metastat -c
d200 m 219GB d20 d40
d106 m 2.0GB d16 d36
d105 m 50GB d15 d35
d15 s 50GB c1t0d0s5
d35 s 50GB c1t2d0s5
d104 m 202GB d14 d34
d201 m 60GB d21 d41
d21 s 60GB c1t1d0s1
d41 s 60GB c1t3d0s1
d103 m 4.0GB d13 d33
d100 m 5.0GB d10 d30
d101 m 15GB d11 d31
d11 s 15GB c1t0d0s1
d31 s 15GB c1t2d0s1

2.

this:
# metastat -c
d201 m 60GB d21
d21 s 60GB c1t1d0s1
d200 m 219GB d20
d106 m 2.0GB d16
d105 m 50GB d15
d15 s 50GB c1t0d0s5
d104 m 202GB d14
d103 m 4.0GB d13
d100 m 5.0GB d10
d101 m 15GB d11
d11 s 15GB c1t0d0s1
d41 s 60GB c1t3d0s1
d35 s 50GB c1t2d0s5
d31 s 15GB c1t2d0s1

Reattaching Slave Disk to the Mirror-HA Solaris

d201 m 60GB d21
d21 s 60GB c1t1d0s1
d200 m 219GB d20
d106 m 2.0GB d16
d105 m 50GB d15
d15 s 50GB c1t0d0s5
d104 m 202GB d14
d103 m 4.0GB d13
d100 m 5.0GB d10
d101 m 15GB d11
d11 s 15GB c1t0d0s1
d41 s 60GB c1t3d0s1
d35 s 50GB c1t2d0s5
d31 s 15GB c1t2d0s1


d200 m 219GB d20 d40

d106 m 2.0GB d16 d36
d105 m 50GB d15 d35
d15 s 50GB c1t0d0s5
d35 s 50GB c1t2d0s5
d104 m 202GB d14 d34
d201 m 60GB d21 d41
d21 s 60GB c1t1d0s1
d41 s 60GB c1t3d0s1
d103 m 4.0GB d13 d33
d100 m 5.0GB d10 d30
d101 m 15GB d11 d31
d11 s 15GB c1t0d0s1
d31 s 15GB c1t2d0s1
Replacing Disks-HA Solaris
disk:
# metadb


2.

# cfgadm -al
the failed disk.

8.
# metastat -c
d106 m 516MB d16 d26 (maint)

d105 m 109GB d15 d25 (maint)
d104 m 2.0GB d14 d24 (maint)
d103 m 3.0GB d13 d23 (maint)
d100 m 6.0GB d10 d20 (maint)
d11 s 15GB c1t0d0s1

Monitoring Disk Mirror Health-HA Solaris
dmchk.conf file (see "Customizing Health Monitoring").
Customizing Health Monitoring-HA Solaris


Name
mirror status.


errors.

#
#
#
#smtp.host = plato

#
#
# Example:
#
#
#

#
#
#smtp.from = root

#
#
#smtp.timeout = 60

#
#
#smtp.debug = 0

# Possible values:
#
# default: 1
#send.mail = 1

#
#
Debug Logs-HA Solaris

Configuring Alternative Boot Device-HA Solaris

# init 0
ok printenv nvramrc

ok nvstore

ok boot
ok boot disk2
Customizing Disk Mirror Configuration-HA Solaris

# ---------------------------------------------------------------------
# ---------------------------------------------------------------------
svm.mirror.id = 1
# ---------------------------------------------------------------------
# ---------------------------------------------------------------------
svm.mirror.id = 2
Insight Server Administration-HA Solaris


Expected output:

PKGINST: SONSems
NAME: Sonus Insight
ARCH: sparc
pathnames 7
linked files 1780
directories 3288
$ ./sonusEms status
When you run ./sonusEms status on an HA system, the information displayed in Checking the HA Status is also
displayed.
$ ./sonusEms start

HA related messages that appear during the sonusEms start are shown in "HA Messages During sonusEms
start".
# ./sonusEms -help
$ ./sonusEms stop
HA related messages that appear during the sonusEms stop are shown in " HA Messages During sonusEms stop"
procedure. Instead, use "Changing the host name for Insight without Changing the IP Address".



b. Respond y.

c/hosts
7. Start Insight.
8. Disassociate all registered nodes with the old IP address (see “Managed Device Association” in the
Insight Administration chapter of the Insight EMS User Guide).
procedure. Instead, use "Changing the IP Address of Insight".


2.


Respond y.


changed.
Insight Server Backup and Restore-HA Solaris

backup files.

EMS Solaris

release.
Release.
Release.

not stable.
Release.
Release.
High-level Steps:
sustaining release.
System Backup

1. (Optional) Kickstart the EMS Solaris system with respective EMS Release from which backup was taken, if
the EMS Solaris system is not stable. For more details, about EMS Release from which you want to kickstart,
refer the above Table.
a. As root, enter the following commands:

b. The following message appears:

Respond y.

c.
d. Perform the EMS HA Configuration and complete perform post-installation tasks..
2. Log in as root.
directory.
or
or
file names:
CAUTION

# ./emsMigrate.sh
used.
the following:
#.)
and #.)

Enter N.

Passwords

Lowercase letters
Uppercase letters
Numbers
Special characters
Insight Server Database Administration-HA Solaris


Restoring the Inisght Database

$ sqlplus /nolog
SQL> startup
SQL> exit
$ sqlplus /nolog
SQL> exit

$ lsnrctl start
$ lsnrctl stop
$ lsnrctl status
displayed.
system restore, see Insight Server System Backup and Restore.
strategy.
3.

$ export_manual.sh
database.
errors.
CAUTION
to shut down Sonus Insight refer to the procedure, Stopping the Insight Server.
database.
following:

following:
Starting and Stopping the Insight Database-HA Solaris

$ sqlplus /nolog
SQL> startup
SQL> exit

$ sqlplus /nolog
SQL> exit
Netcool Configuration-HA Solaris

On this page:


parameters.
default.
Insight Server Administration. If you want to start, stop, or check the status of the Netcool processes separately from
the Insight server, use the following commands.

HA Insight Server Administration

This section contains the following HA Insight server administrative tasks:
HA Manual Failover
Checking the HA Status
HA Messages During sonusEms start
Active System Success
Standby System Success
Active or Standby System Issues
HA Messages During sonusEms stop
HA Logs
Location of Logs
HA Audit Log
Agent Trace Log
RAID Lock Mechanism
Rebooting an HA Server
Shutting down an HA Server
Removing a Node from Cluster
Converting an HA System to Standalone
Overview
Prerequisite
Creating Database Dump File
Creating Netcool Dump Files
Running configure HA to convert an HA system to Standalone

HA Manual Failover
It may become necessary in a HA system, either as a planned event or due to an incomplete automatic failover, to
initiate a manual failover from the active to the standby system. Perform the following to initiate a failover:
1. As user insight, enter the following:
$ ./sonusEms failOver
The success or failure of the failover is displayed. The possible messages are:
"Operation successfully completed."

"Error connecting to agent."
"Error connecting to agent on the peer system."
"Fail over is aborted because the peer system is in UNKNOWN state."
"Active failed to become Standby because "ReleaseResources" failed. Fail over
did not complete."
"Standby failed to become Active because "TakeoverResources" failed. Fail over
did not complete."
"Standby failed to become Active because "sonusEms start" failed. Fail over
did not complete."
If the failover was not successful, contact the Sonus TAC.
To check the HA status of an Insight server, perform the following procedure.
When you run sonusEms status, you will also see the information described in Step 3.
1. Login to the system as root.

2. Navigate to the HA directory as follows:
# ./hamgmt getState
The actual state and the configured state of the server are displayed. The possible states are:
UNKNOWN
ACTIVE

STANDBY
ACTIVE_INTENT (attempted to become active but failed because the required resources were not
available)
STANDBY_INTENT (attempted to become standby but failed because the presently owned resources
could not be relinquished)
The following information about resources held by the system will also be displayed:
Whether the logical IP is published on this system.
Whether the RAID is mounted by this system.
Whether database processes are running on this system.
During a successful sonusEms start on the active system, the following messages are displayed:
Trying to connect to HA
This system is configured for High Availability support.
Commencing HA startup now.
Fail over control has been initialized.
This system is the Active HA system. The Insight processes will now be started.
During a successful sonusEms start on the standby system, the following messages are displayed:
This system is the Standby HA system. Only some of the Insight processes will be
started.
During an unsuccessful sonusEms start on the active or standby system, the following HA issues can be displayed:
Failed to contact Fail over control!

The system failed to become Active because "TakeoverResources" failed. Its state is
set to UNKNOWN.
"Fail over control has not been initialized because the system is not in UNKNOWN
state."
"Failed to initialize Fail over control!"
During a sonusEms stop on the active or standby system, the following messages are displayed:

Stopping HA Fail over control now.
Fail over control has been stopped.
HA Logs
Location of Logs
The ha_audit_log and the agent_trace_log files are located under the directory <agent_home>/logs.
The <agent_home> directory is the location in which the Sonus agent is installed. You can find this name by
typing:
# echo `pkgparam SONScomm BASEDIR`/sonusComm
HA Audit Log
The ha_audit_log contains logging statements for the time of HA transitions, the previous HA state of the
system, and the current HA state of the system.
Agent Trace Log
The agent_trace_log contains logging statements for FailOverControl, heartbeat, system check, and
auto-starting related issues.
RAID Lock Mechanism
To prevent an Oracle data corruption, a new functionality RAID Lock Mechanism is added. Any server that is active,
locks the RAID with its signature and unlocks it during switchover. The server cannot mount the RAID, if it is locked
by the peer.
To reboot one of the HA servers, use the following command:
# reboot
The failover successfully happens after the rebooted active server comes up. The RAID lock is released after the
server comes up.
To shutdown the HA servers, use the following command:

# shutdown
If the active server is shutdown, it will not trigger a switchover, because the active server still retains the
lock. To shutdown the active server, first the switchover has to be triggered and then the Node has to be
shutdown.
To remove a Node from a cluster, use the following command:
/opt/sonus/ems/conf/HA/RAC/hamgmt shutdownNode
Overview
This section describes how to convert either the active or standby system to a standalone system by running
configureHA and selecting option 8.
This process points the database instance to the local database files and sets the IP address of the system to the
previously configured reachability address for the system.
Prerequisite
Before performing the procedure Running configure HA to convert an HA system to Standalone, place database
dump files on the system by performing the following procedure:
Perform the following procedure to create Database Dump File:
1. As user oracle on system A (the active system), export the existing database by entering the following
commands on system A:
$ cd <ORACLE_BASE>/backup/bin
$ ./export.sh
The script generates two exported files, exp_data.dmp and exp_strct.dmp and puts them in
<ORACLE_BASE>/backup/dump. Sonus recommends that you copy these files to an external location as an
additional safety precaution.
2. If you are converting the standby system (system B) to standalone, then as user oracle, move the two
exported files generated in Step 1 to system B. Place them in:<ORACLE_BASE>/backup/dump
Perform the following procedure to create Netcool Dump Files:

1. Perform the following steps on the Active System as user insight.
a. Enter the following command to create a directory to hold a backup of the fault database
mkdir -p /export/home/netcool/omnibus/db.bak
and place it in the below path:
/export/home/ems/conf/netcool/netcooladmin/backupDB.sh -d
/export/home/netcool/omnibus/db.bak
The path does not contain a line break and there should be one space after -d
Perform the following procedure to convert an HA system into a standalone EMS:
1. Run haMigrateFiles.sh script on Active system to move the reports and PM files from RAID.
Ensure that the RAID is mounted before running haMigrateFiles.sh.
a. Login as user insight on Active system and stop EMS.
./sonusEms stop
b. Login as root in the Active system and enter the following commands to start the
haMigrateFiles.sh script.
From the list of options, select 4 “Migrate All back to Standalone

2. Run haMigrateFiles.sh script on Standby system to move the reports and PM files from RAID.
a. Login as user insight on Standby system and stop EMS.
./sonusEms stop
b. Release resources on Active system, login as root in Active system and release resources.
# ./haResources release

c. Takeover resources on Standby system, login as root in Standby system and takeover resources.
# ./haResources takeover
d. Login as root in the Standby system and enter the following commands to start the haMigrateFiles.sh
script.
e. Release resources on Standby system, login as root in Standby system and release resources.
From the list of options, select 4 “Migrate All back to Standalone”
3. Takeover resources on Active system, login as root in Active system and takeover resources:
4. As root on the system that you are converting to standalone, enter the following command to start the
configureHA script:
# ./configureHA
5. The system displays the HA configuration Main menu:

This option will convert your system to standalone mode. Do you want to
proceed? (default: n) [y,n]

7.
Have you copied Oracle dump files in /export/home/oracle/backup/dump dir?

(default: no) [y,n]
Importing the database does not import historical performance management data
and user activity logs because this may take several hours to complete.
Enter yes if you wish to do the stats import, or no to skip importing the
stats.? (default: no) [y,n]
If you want to restore historical performance management data and user activity logs (this can take several
hours), type Y and press enter. Otherwise, type n and press Enter.
9. The system displays one of the following, depending on your response in Step 8:
You selected to import historical performance management data and user

activity logs. Is that correct? (default: no) [y,n]
You selected to not import historical performance management data and user
(default: no) [y,n]
To notify all the IASs that were registered to the HA system of the new standalone system’s IP address, type
y and press Enter. Otherwise, type n and press Enter.
You selected to notify the registered IAS systems. Is that correct? (default:
no) [y,n]
You selected to not notify the registered IAS systems. Is that correct?
(default: no) [y,n]

12.
Do you wish to import a backup of a Fault database or create a new one?

[import,create]:
Enter either import or create.
13. If you entered create in Step 12, skip to Step 16.

If you entered import in Step 12 and you are converting a standby system to standalone, continue to Step 14.
If you entered import in Step 12 and you are converting an active system to standalone, skip to Step 16.
14. Migrate fault data from the active system to the standby system as follows:
a. Open a second window on the standby system and as user insight, remove the symbolic link and
create the local directory:
/bin/rm /export/home/netcool/omnibus/db
mkdir -p /export/home/netcool/omnibus/db/SONUSDB
b. Copy the files created on, see Creating Netcool Dump Files, to Standby.
For example:
scp /export/home/netcool/omnibus/db.bak/*.tab
insight@<systemB>:/export/home/netcool/omnibus/db/SONUSDB
where <systemB> is the local reachability IP address for the standby system.
(the above example does not contain a line break, and there should be only one
space after *.tab)
15. If you entered import in Step 12, the system displays the following:
To import a saved Netcool database to the local system, you need to have
table_store.tab and master_store.tab files.
Do you have access to table_store.tab and master_store.tab files? (default:
no) [y,n] y

16. When the conversion to standalone is complete, the following is displayed:

This system is configured as Standalone. Sonus Insight server should be
started as user 'insight'.
3) Input the IP Multipath and Insight Reachability information.
q) quit
17. As user insight, start Insight:
Ignore the following step if the procedure is performed as part of Disaster Recovery Upgrade.
18. Rediscover all the managed nodes:

a. As a user with administrative privileges, go to the Node tab in the Insight Administration page.
b. Select a node from the Sonus Managed Nodes list, and click the Discover button.
Account Management-HA Solaris


Idle Session Logout
next section.
values.

restrictions.
definact=90
Idle Session Logout
TMOUT=1800
TMOUT=1800
export TMOUT
Uninstalling Sonus Insight-HA Solaris


# cd /tmp
# ./emsUnInstall.sh

Changing Netcool DB Object Server Name for Solaris HA

name.
1.

1. On Active server get the netcool DB name from /export/raid/Omnibus/db/{DB_NAME}
2. Stop EMS as user insight on standby serverby running the following command:
3. Stop EMS as user insight on active server by running the following command:
4. As root user execute the following script on active server:

7. As root user execute the following script on secondary server:

9.

10. Start EMS as user insight on Active Server by running the following command:
11. Start EMS as user insight on Secondary Server by running the following command:
Limitation
Upgrading StorageTek Firmware for HA Setup
This section describes the procedure for upgrading StorageTek 2540 Array firmware upgrade using CAM Host
Management Software GUI. Insight V09.02.00 Release supports CAM Software version 6.7.0.12 and it suggests the
baseline firmware version for StorageTek 2540 Array is 07.35.55.11.
Insight V09.02.00 upgrade procedure is required to upgrade StorageTek Array firmware to the baseline firmware
version.
Prerequisites for upgrading StorageTek Firmware
In order to perform the upgrade effortlessly it is recommended to use the following supported browsers for
StorageTek Firmware upgrade with CAM 6.7 host management software.
Firefox 3.0
Microsoft Internet Explorer 6.0
Internet Explorer Versions 7 and 8 are not supported.
Enabling Remote Access to Oracle Java Web Console in Host Machine
Solaris OS 10 generally restricts port 6789 to listen to localhost only. This setting should be changed to enable
remote access to the Oracle Java Web Console and the Sun Storage Common Array Manager.
Perform the following steps in the Host Machine (controlling/using StorageTek Array) to enable console server to

respond to network requests.
1. Become superuser or assume an equivalent role on the system where the console is running.
2. Set a property to allow the console server to respond to network requests, refresh the service, and restart the
console server.
3. Execute the following commands:
# svccfg -s svc:/system/webconsole setprop options/tcp_listen=true

# svcadm refresh svc:/system/webconsole:console
# /usr/sbin/smcwebserver restart
StorageTek Array and Host Machine Information
Perform the following steps to acquire the StorageTek Array and Host Machine information.
1. The IP address of data Host machine (where the CAM software is installed and which can access the array
over the network/Ethernet). Also, note the IP address of StorageTek array controllers.
2. Login to the data host machine with root privilege and ensure that CAM CLI version is 6.7.0.12. Execute
below command.
# /opt/SUNWstkcam/bin/sscs --version
The following output is expected:
Sun Storage Common Array Manager v6.7.0.12
3. Log in to the /export/home/packages directory as a root user using the following command:
cd /export/home/packages
unzip 145965-03.zip
The 145965-03.zip file is also available from the Sonus Salesforce Customer Portal.
5. Change the directory to 145965-03.
cd 145965-03

6.
pkgadd -Gd . SUNWc2500
7. The following is displayed. Enter Y.
This package contains scripts which will be executed with super-user

permission during the process of installing this package.
Do you want to continue with the installation of <SUNWc2500> [y,n,?] y
8. After the installation complete, the following message is displayed.
Installation of <SUNWc2500> was successful.
StorageTek Firmware Upgrade
Perform the following procedure to upgrade the StorageTek Firmeware:
1. Open a web browser and point to the URL https://<IP_Address_of_the_DataHost>:6789. The

following screen is displayed.
2. Enter the root user credentials to login.
3. The following screen is displayed, after you login successfully.

4. Click the Sun Storage Common Array Manager link. The following screen is displayed.
5. Click the button to start the registration for the array. The following screen is displayed.

6. Select the option Enter IP address or hostname.
7. Enter the hostname or IP address of the RAID controller in IP Address. The user can also select the Scan the
local network option to discover the array.
8. Click the button. The following screen shows the progress of discovery process.
9. When progress is complete, click the button. The following screen is displayed.

10. Click the button to start the registration process. The following screen shows the progress of the
registration process.
11. When the registration is successful, The following screen is displayed.
12. Click the button. The following screen is displayed.

12.
13. Click the Storage System from the navigation panel on the left hand side of the screen.
14. Select the array using the checkbox and click the button. The following screen
is displayed.
15. Click the button to analyse the storage system firmware.

16. If the current firmware version is lower than baseline firmware proceed with the upgrade. The following
screen is displayed as an example.

17. Click the button to start the firmware upgrade process. The following screen is displayed.
18. Enter the valid password if the screen prompts and then click the button.
19. When the upgrade is complete, review the results and click the button to return to the main menu.
20. The Main Menu should contain the firmware version 07.35.55.11 for StorageTek Array.
Migrating Insight HA 240 or 440 to Netra T5220s
This section describes how to migrate an existing Insight HA system from Netra 240 or Netra 440 systems to Netra
T5220 systems.
Insight User Guide.

V09.02.00. Hence, after you have migrated data to V09.02.00 Release with T5220 you can upgrade from
V09.02.00 to V09.03.00 or V09.02.01 and higher sustaining releases.
Restrictions
Hardware Setup
Task Sequence for Migrating HA to Netra T5220s
Exporting Data from the HA System
Setup and Configure Netra T5220 platforms with RAID Disk Arrays-HA Setup
Netra T5220 Disk Labeling and File System Creation for the RAID Disk Array-HA Setup
Private Network Setup for HA Deployment
Public Network Setup for HA Deployment
Importing Data into the Netra T5220s
The configureHA Script-HA Setup
Checking Interface Configuration and Routing Table for Netra T5220-HA Setup
Restrictions
Migration from 240/440 to 5220 is not supported for any releases after EMS V09.02.00
The active and standby systems must be on the same type of server (both servers must be a Netra T5220).
request.
Hardware Setup
Quad GigENET PCI-E card installed on each Netra T5220.
Task Sequence for Migrating HA to Netra T5220s

To migrate an existing Insight HA system from Netra 240/440 servers to Netra T5220 servers, perform the following
tasks in the sequence given:
1. Export the data from HA server (perform on the Netra 240/440 servers). For details, see Exporting Data from
the HA System.
2. Kickstart EMS HA on Solaris Netra T5220 system with EMS Release V09.02.00.

2.
Perform the step 3 to step 9 on EMS HA Netra 5220 to install V09.02.00, configure HA, restore
data using EMS V09.02.00 Software Release. After data is restored on EMS V09.02.00, you can
upgrade from V09.02.00 to V09.03.00 Release.
3. Setup and configure RAID Disk Array with Netra 5220:

a. Setting up and configuring IBM DS3524 Storage System:
i. Netra T5220 and IBM DS3524 Storage System Connections.
ii. IBM DS Storage Manager Software Installation.
iii. IBM DS3524 RAID Disk Array Configuration on Insight EMS Servers.
b. Setting Up and Configuring Netra T5220 Systems with StorageTek 2540 Disk Array
4. Perform disk labeling and file creation for RAID Disk Array. See Performing Netra T5220 Disk Labeling and
File System Creation for the RAID Disk Array (perform on both the active and standby Netra T5220 servers).
5. Setup private network. See Private Network Setup.
6. Setup public network. See Public Network Setup.
7. Import the data back to the HA servers. For detailed procedure, see Importing Data into the Netra T5220s
(perform on both the active and standby Netra T5220 servers).
8. Run configureHA on both the active and standby Netra T5220 servers. See The configureHA Script.
9. Verify interface and routing table on both the active and standby Netra T5220 servers. See Checking
Interface Configuration and Routing Table for Netra T5220.
10. Upgrade from EMS Software Release V09.02.00 to V09.03.00. For more information on upgrade, refer
Upgrading from V09.02.00 to V09.03.00 Software Release.
Exporting Data from the HA System

Export the data from your existing HA servers by performing the following procedure, which generates three files for
the active system and three files for the standby system. Later in the sub-sequent section you will need to import
these files into the new Netra T5220 systems.
exp_data_manual.dmp
1. Log on to the Netra 240/440 active system (system A) as a user with root privileges.
2. Run the manualBackup.sh script on system A:
to store your backup files. Use a directory that is external to the Insight machine and that is accessible from

the Netra T5220 that will be the new active HA system. Use a directory name that will clearly identify the EMS
server that created the backup files. Make a note of the directory path because you will need it later when
migrating data to the Netra T5220 active HA system.
3. The script returns the following text:
The backup results in the creation of three files (backupFiles.tar, exp_data_manual.dmp, and
exp_strct_manual.dmp) in the backup directory you identified in Step 2.
4. Perform a failover from the Netra 240/440 active system (system A) to the Netra 240/440 standby system
(system B) as follows:
a. Log on to system A as a user with root privileges.
b. Enter the following on system A:
c. Enter the following on system A:
# ./hamgmt failOver
5. Run the manualBackup.sh script on system B:
the Netra T5220 that will be the new standby HA system. Make a note of the directory path because you will
need it later when migrating data to the Netra T5220 standby HA system.

Setup and Configure Netra T5220 platforms with RAID Disk Arrays-HA Setup
Setting Up and Configuring Netra T5220 Systems with IBM DS3524 Storage System-HA
Setup
system.
Storage System:

Netra T5220 and IBM DS3524 Storage System Connections-HA Setup
T5220 systems.

IBM DS Storage Manager Software Installation-HA Setup


archive...
..
.....
......
....
.....
IBM DS3524 Storage Subsystem Controller IP Address Configuration-HA Setup

4Gbps, and 2Gbps
enclosures

servers.
servers.
export DISPLAY
echo $DISPLAY
# ./SMclient

Management window.
discovery.
for the password.
192.168.128.101 Port 1
192.168.129.101 Port 2
addresses.
IBM DS3524 RAID Disk Array Configuration on Insight EMS Servers-HA Setup
configuration.
For example,


Unnamed 10.54.58.94 10.54.58.95

For example,
EMSIBMRAID\";"
# SMcli -i -d
# SMcli -i -d
EMSIBMRAID 10.54.58.109 10.54.58.110


7.

1. for 146GB
2. for 300GB

1. for 136GB
2. for 270GB
For example, 10.54.58.109.

Enter.
SONSemsarray )
EMSIBMRAID
....
...
...
some time
#

12.

12. Reboot EMS.
# reboot -- -r
Setting Up and Configuring Netra T5220 Systems with StorageTek 2540 Disk Array-HA
Setup
Array.

RAID Disk Array Controller IP Address Configuration-HA Setup
controllers.

==============================
Q) Quit Menu
Enter Selection:
Enter 2.
Enable IPv4 (Y/N)?
Enter Y.

Enter N.



Subnet Mask : 255.255.255.0

Netra T5220 and RAID Disk Array Connections-HA Setup

or nxge3.
StorageTek Common Array Manager Software Installation-HA Setup
1.

Install Solaris Patch
For more details on Solaris Patch, see Upgrading Insight High Availability.
StorageTek 2540 RAID Disk Array Configuration on Insight EMS Servers-HA Setup


3.

SONSemsarray.

Netra T5220 Disk Labeling and File System Creation for the RAID Disk
Array-HA Setup
Active System
1. Log on as root.
# format

ssd@w202500a0b85a427e,1f
ssd@w202400a0b85a427e,0
ssd@w202400a0b85a427e,1f



1060 cyl 53502 alt 2 hd 512 sec 64>

number):

selecting c2t2d0
[disk formatted]
Enter yes.

/export/raid:

d.
total 16
lost+found
# df -h|grep raid
# df -h|grep raid
becomes active.
Standby System
system.


# format
ssd@w203400a0b867dc82,0
64>
ssd@w203400a0b867dc82,1f
ssd@w203300a0b867dc82,0
64>


64>

64>

1060 cyl 53502 alt 2 hd 512 sec 64>

number):
/export/raid:

total 16
# df -h|grep raid

# df -h| grep raid
becomes active.
Private Network Setup for HA Deployment

minimum number of private network connections is one; however, the more connections that you provide, the more
protection you have against port and card failures.
failure).
systems.
Procedure
systems.
5220 systems. The Table "Private Network Interfaces and IP Addresses" shows the recommended interfaces

2.
across reboots) IP addresses to the private network interfaces you connected in Step 1. The Table Table "
Private Network Interfaces and IP Addresses" shows a sample IP address to use for each interface. Note that
the first private network link is on a different subnet than the second private network link, as required.
b. Record the value of each IP address in Table 14 – 4; you will need these values when running the
configureHA script.
interfaces on the system.
Depending on the private network interface IP address, specify the Network number and subnet mask
of the respective private network interface.
Example:
If the private network interface number is 192.168.5.2 then enter the network number and subnet mask
in /etc/netmasks file as 192.168.5.0 255.255.255.0.
This example considers e1000g2 as the private interface and 255.255.255.0 as the netmask.

e. Restart the network services svcadm.

System Item Value

Public Network Setup for HA Deployment


Prerequisite
configureHA script.
System Item Value
Requirements
allowed.
Procedure
2. Log on as root.

3.

Record the value Table 3 – 4, you will need it when running the configureHA script.
Caution

System Item Value

Importing Data into the Netra T5220s

Use the following procedure to import the data that you earlier exported from your Netra 240/440 HA system (see "
Exporting Data from the HA System"). The Netcool database is also imported.
Perform the procedure on both the active and standby Netra T5220 servers.
Passwords
passwords.

lowercase letters
uppercase letters
numbers

special characters
Procedure
Perform the following procedure on both the active and standby Netra T5220 servers to import the data you earlier
exported from the Netra 240/440s:
This task need to be done on both the active and standby servers.
1. Log on to both the Netra T5220 servers as root.

2. Copy the backup files to both the active and standby servers.
The files need to copied from respective backups, that is, active or standby.
For example, If this Netra T5220 is the active system, then from the active system backup directory you used
in Step "2" of "Exporting Data from the HA System", copy the exp_data_manual.dmp and
exp_strct_manual.dmp files to the /export/home/oracle/backup/dump directory on the Netra
T5220. Also copy the backupFiles.tar file to the /tmp directory on the Netra T5220.
If the exp_data_manual.dmp and exp_strct_manual.dmp files are copied to
/export/home/oracle/backup/dump using an unconventional method, such as FTP, change the owner
and group of the files to Oracle and DBA.
CAUTION
# ./emsMigrate.sh

###########################################################################################
already
migrating

replaced
###########################################################################################Do
you wish to continue [y|Y,n|N] ?

Done
..............................................................................................
[y|Y,n|N] ?

*****************************************************************************
*****************************************************************************
#############################################################################################
oracle.
#############################################################################################
..............................................................................................
64bit Production
Done
Insight User Guide.
8. Repeat this procedure for the other Netra T5220.
The configureHA Script-HA Setup

for the first time.
Prerequisites
system information. The Table System Information Worksheet lists the information you will need, and the
procedures in which these values were assigned. You can enter your values into the table and use it as a reference
when you run configureHA.
Performed the first five items in Task Sequence for Migrating HA to Netra T5220s
Reset the insight user password. See "Changing the "insight" User Password and/or Password Expiration

Behavior". The active and standby systems must use the same insight user password.


assigned

(Optional)

multipath group
Test address (IPv4/IPv6/both) for secondfary interface for Step 19

multipath group

System Creation for the RAID Disk
RAID device name Array-HA Setup

multipath group

multipath group

(Optional)

RAID device name Array-HA Setup

to both

Configure HA on EMS systems-HA Setup
Configuring HA on Active System-HA Setup

$ sqlplus /nolog
SQL> startup
SQL> exit

# ./configureHA

information.
q) quit

information.

q) quit


PSX.


information.

q) quit

functionality.
The
The
e1000g0
e1000g1
e1000g2
nxge0
nxge1

interface.

an option.

HA-PUB-GRP):


[y|n]:n
or
10.54.5.32) : 10.54.5.32

Setup.

10.54.5.34
Enter.




[y|n]:
or
Alives.
and press Enter.
You entered:




31.
You entered...
User Name: "oracle"
Group Name: "dba"


(default:)...



system startup.

q) quit

created...default:
/export/home/oracle


Testing scp



(default: no) [y,n]
47.


current hostname.

Configuring HA on Standby System-HA Setup
The procedure for running the configureHA script on a standby system is similar to the procedure for an active
system, but both the Insight process and database instance should be stopped. Use the procedure detailed in "
Configuring HA on Active System-HA Setup" with the following differences:
In "step1", ensure that the database instance is stopped.

In "this step", when the script asks:

respond with an s instead of accepting the default value. The system then displays the following message:
This system will be configured as a standby system.
In "this step", when the system asks:

You must choose a different operation than you chose for the active system. If you chose item 1 for the
active system, you must choose item 2 for the standby system. Press Enter after making your selection.
The system then displays several status messages.
In "this step", when the system asks

Performing Post-HA Configuration Tasks-HA Setup
Table 89: Performing Post-Configure HA Tasks
Step Number Tasks
1. Verify that the interfaces and routing table are configured correctly.
See Checking Interface Configuration and Routing Table for Netra T5220-HA Setup.
3. First start Insight on the active system and then on the standby system
After migrating data from one EMS server (A) to another EMS server (B), and after registering Insight node B,
you need to unregister Insight node A (which will show up registered as a result of the migration).
Associate the new Insight IP with the nodes. For information, see Associating the Nodes-HA Setup.
Disassociate the old Insight IP from the nodes. For information, see Disassociating the Nodes-HA Setup.

1. Login to Insight
a. SSH Port
b. Login (CLI)
c. Password (CLI)
5. Click on Update button and then click on Discover node
Associating the Nodes-HA Setup



d.
e. Click OK.
Disassociating the Nodes-HA Setup



e. Click OK.

Checking Interface Configuration and Routing Table for Netra T5220-HA
Setup
Example Details

192.168.5.1.
Procedure
Use the following steps to verify the interface configuration and routing table on each server that is part of an HA
setup.
ifconfig -a

1
index 2
10.10.222.255
ether 0:14:4f:4f:c0:35
10.10.222.255
ether 0:14:4f:4f:c0:36
nxge0:1:
1500 index 29
10.10.222.255
ether 0:14:4f:4f:c0:37
10.10.222.255
ether 0:14:4f:42:64:8c
e1000g1:1:
1500 index 28
10.10.222.255
ether 0:14:4f:42:64:8e
netstat -rn

Routing Table: IPv4
----------------- -------------- ----- ----- ---- ----------
192.168.5.0 192.168.5.1 U 1 46522 nxge1
192.168.6.0 192.168.6.1 U 1 5585 e1000g2
10.10.222.0 10.10.222.30 U 1 284 e1000g1
10.10.222.0 10.10.222.37 U 1 23 nxge0
10.10.222.0 10.10.222.30 U 1 0 e1000g1:1
10.10.222.0 10.10.222.30 U 1 0 nxge0:1
224.0.0.0 10.10.222.31 U 1 0 e1000g0
default 10.10.222.1 UG 1 174989
127.0.0.1 127.0.0.1 UH 33100429493 lo0

V09.03.00 Release. For more information about upgrading, refer the section Upgrading Insight High Availability.
Migrating From Storage Tek RAID to IBM RAID on T5220
This section describes how to migrate from Storage Tek RAID to IBM RAID on Netra T5220.
If you are using a pre-9.0.0 EMS Solaris with StorageTEK RAID and want to migrate to IBM DS3524 RAID
then you must migrate using EMS V09.02.00 release. Direct migration from EMS pre-9.0.0 Release with
StorageTEK RAID to V09.03.00 Release with IBM DS3524 RAID is not supported. Jumpstart EMS Solaris
HA with IBM DS3524 RAID running on V09.02.00 and then perform migration. After you have migrated data
to V09.02.00 Release with IBM DS3524 RAID you can upgrade from V09.02.00 to V09.03.00 or V09.02.01
and higher sustaining releases.

Table 90: Migration Files when Exporting from EMS Solaris StorageTEK RAID
When Migrating from EMS Migration Files generated are High-level migration Steps
Solaris StorageTEK RAID
Pre-9.0.0 Release backupFiles.tar 1. Jumpstart with EMS V09.02.00

Software Release connected to IBM
exp_data_manual.dmp
DS3524 RAID.
exp_strct_manual.dmp 2. Import the migration files on EMS
V09.02.00 Release.
3. Upgrade from V09.02.00 to
V09.03.00.
9.2.0 Release backupFiles.tar 1. Jumpstart with EMS V09.02.00

DS3524 RAID.
expdp_strct_manual.dmp 2. Import the migration files on EMS
V09.02.00 Release.
V09.03.00.
9.2.1 Release and above backupFiles.tar 1. Jumpstart with EMS V09.02.00

DS3524 RAID
expdp_stats_data_manual.dmp 2. Upgrade from V09.02.00 to V09.03.00
3. Import the migration files on EMS
expdp_strct_manual.dmp V09.03.00 Release.
Restrictions for Configuring Insight HA

Hardware Requirements for Migration
High-level Tasks for Migrating From Storage Tek RAID to IBM RAID on T5220
Exporting Data from Active and Standby Server
Setup and Configure Netra T5220 platforms with RAID Disk Arrays for Migration
Performing Netra T5220 Disk Labeling and File System Creation for the RAID Disk Array
Private Network Deployment
Public Network Deployment
Importing Data into the Netra T5220s for Migration
Configuring High Availability on each Netra System for Migration
Upgrading from Insight EMS V09.02.00 to V09.03.00 Software Release
Restrictions for Configuring Insight HA

request.

Hardware Requirements for Migration

High-level Tasks for Migrating From Storage Tek RAID to IBM RAID on T5220
This section describes the procedure for migrating the Storage TEK RAID to IBM RAID on Netra T5220.
Table 91: Migrating from Storage TEK RAID to IBM RAID on T5220 for pre-9.0.0 or 9.2.0 Release
Step Task
Number
1. Take database backup on T5220s with STK RAID on previous versions.
For detailed procedure, see Exporting Data from the HA System.
Perform the step 3 to step 9 on EMS HA Netra 5220 to install V09.02.00, configure HA,
restore data using EMS V09.02.00 Software Release. After data is restored on EMS V09.02.00,
you can upgrade from V09.02.00 to V09.03.00 Release.
3. Setup and configure RAID Disk Array with Netra 5220. For detailed procedure, see Setup and Configure Netra
T5220 platforms with RAID Disk Arrays.
4. Perform disk labeling and file creation for RAID Disk Array. See Netra T5220 Disk Labeling and File System
Creation for the RAID Disk Array-HA Setup.
5. Setup private network. See Private Network Deployment .
6. Setup public network. See Public Network Deployment.
7. Import the data back to the HA servers. For detailed procedure, see Importing Data into the Netra T5220s .
8. Configure HA using same old T5220s with new IBM RAID. For detailed procedure, see The configureHA
Script-HA Setup.
9. Verify interface and routing table. See Checking Interface Configuration and Routing Table for Netra T5220.
10. Upgrade from EMS Software Release V09.02.00 to V09.03.00. For more information on upgrade, refer Upgradin
g from Insight EMS V09.02.00 to V09.03.00 Software Release.
If you are migrating from 9.2.1 StorageTEK RAID to 9.3.0 release with IBM 3524 RAID, following will be the
high-level steps:

Table 92: Migrating from 9.2.1 Storage TEK RAID to 9.3.0 with IBM RAID
Step Task
Number
For detailed procedure, see Exporting Data from the HA System.
2. Kickstart EMS HA on Solaris Netra T5220 system connected to IBM DS 3524 RAID with EMS Release
V09.02.00.
Perform the step 3 to step 9 on EMS HA Netra 5220 connected to IBM DS 3524 RAID to
install V09.02.00 and upgrade to EMS V09.03.00 Software Release. After upgrading to EMS
V09.03.00, you can import the migration files to V09.03.00 Release.
T5220 platforms with RAID Disk Arrays.
Creation for the RAID Disk Array-HA Setup.
5. Setup private network. See Private Network Deployment .
6. Setup public network. See Public Network Deployment.
7. Configure HA using same old T5220s with new IBM RAID. For detailed procedure, see The configureHA
Script-HA Setup.
8. Verify interface and routing table. See Checking Interface Configuration and Routing Table for Netra T5220.
g from Insight EMS V09.02.00 to V09.03.00 Software Release.
10. Import the migration files on EMS V09.03.00 Release. For more details about how to import the migration file,
refer
Exporting Data from Active and Standby Server

Depending on the EMS Software Release from which you are exporting the data, the dmp file names would differ.

When Migrating from EMS Solaris StorageTEK RAID Migration Files generated are
exp_data_manual.dmp
1. Log on to the Netra 5220 active system (system A) connected to StorageTEK RAID as a user with root
privileges.
The backup results in the creation of three files (backupFiles.tar, dmp files) in the backup directory
you identified in Step 2.
4. Perform a failover from the Netra 5220 active system (system A) to the Netra 5220 standby system (system
B) as follows:

b.
# ./hamgmt failOver
Setup and Configure Netra T5220 platforms with RAID Disk Arrays for
Migration
Setting Up and Configuring Netra T5220 Systems with IBM DS3524 Storage System for
Migration
system.

Storage System:

Netra T5220 and IBM DS3524 Storage System Connections for Migration
T5220 systems.

IBM DS Storage Manager Software Installation for Migration


archive...
..
.....
......
....
.....
IBM DS3524 Storage Subsystem Controller IP Address Configuration for Migration
4Gbps, and 2Gbps
enclosures

servers.
2.

servers.
export DISPLAY
echo $DISPLAY
# ./SMclient
Management window.
discovery.
for the password.

12.

192.168.128.101 Port 1
192.168.129.101 Port 2
addresses.
IBM DS3524 RAID Disk Array Configuration on Insight EMS Servers for Migration
configuration.
For example,

Unnamed 10.54.58.94 10.54.58.95

For example,
EMSIBMRAID\";"
# SMcli -i -d
# SMcli -i -d
EMSIBMRAID 10.54.58.109 10.54.58.110


1. for 146GB
2. for 300GB

1. for 136GB
2. for 270GB

For example, 10.54.58.109.

Enter.
SONSemsarray )
EMSIBMRAID
....
...
...
some time
#

12. Reboot EMS.
# reboot -- -r
Performing Netra T5220 Disk Labeling and File System Creation for the RAID
Disk Array

Active System
1. Log on as root.
# format

ssd@w202500a0b85a427e,1f
ssd@w202400a0b85a427e,0
ssd@w202400a0b85a427e,1f


1060 cyl 53502 alt 2 hd 512 sec 64>

number):
selecting c2t2d0
[disk formatted]

Enter yes.

/export/raid:

total 16
lost+found
# df -h|grep raid
# df -h|grep raid
becomes active.
Standby System
system.


# format
ssd@w203400a0b867dc82,0
64>
ssd@w203400a0b867dc82,1f
ssd@w203300a0b867dc82,0
64>


64>

64>

1060 cyl 53502 alt 2 hd 512 sec 64>

number):
/export/raid:

total 16
# df -h|grep raid

# df -h| grep raid
becomes active.
Private Network Deployment

failure).
systems.
Procedure
systems.

2.
configureHA script.
Example:


System Item Value

Public Network Deployment


Prerequisite
configureHA script.
System Item Value
Requirements
allowed.
Procedure
2. Log on as root.

3.

Caution

System Item Value


Use the following procedure to import the data that you earlier exported from your Netra 5220 HA system connected
to StorageTEK RAID (see "Exporting Data "). The Netcool database is also imported.
Passwords
passwords.


lowercase letters
uppercase letters
numbers
special characters
Procedure
Perform the following procedure on both the active and standby Netra T5220 servers connected to IBM DS 3524
RAID to import the data you earlier exported from the Netra 5220 connected with StorageTEK RAID:

in Step "2" of "Exporting Data ", copy the dmp files to the /export/home/oracle/backup/dump
directory on the Netra T5220. Also copy the backupFiles.tar file to the /tmp directory on the Netra
T5220.
If migrating from pre-9.2.0 then use the following dmp file names:
or
If migrating from 9.2.0 then use the following dmp file names:
CAUTION
3.

# ./emsMigrate.sh
##############################################################################################
understand what
you are doing. Before you proceed, you should also have already run
manualBackup.sh on the system
you want to migrate from, which generated backupFiles.tar,
exp_data_manual.dmp, and exp_strct_manual.dmp.
If you are migrating from Solaris to Linux then you should have
NetcoolBackupFiles.tar.

/export/home/oracle/backup/dump and specify
the path for backupFiles.tar at the following prompt.
replaced with the passwords
from the restored data.
##############################################################################################

Done
........................Sonus
[y|Y,n|N] ?
*****************************************************************************
You have chosen to import User Activity Logs, PM Stats and TrunkGroup
Tables.
*****************************************************************************
#######################################################################################
oracle.
#######################################################################################
..............................................................................................
64bit Production
Done
If
you have any IAS registered with the system, then execute the same
Insight User Guide.
Configuring High Availability on each Netra System for Migration

for the first time.

Prerequisites
system information. The table System Information Worksheet lists the information you will need, and the procedures
in which these values were assigned. You can enter your values into the table and use it as a reference when you
run configureHA.
Performed the first five items in High-level Tasks for Migrating From Storage Tek RAID to IBM RAID on
T5220
Reset the insight user password. See Changing the "insight" User Password and/or Password Expiration

assigned
Active First peer private IPv4/IPv6 address Private Network Deployment

(Optional)

multipath group

multipath group
RAID mount point Performing Netra T5220 Disk Labeling

and File System Creation for the RAID
RAID device name Disk Array
Standby First peer private IPv4/IPv6 address Private Network Deployment
Primary interface for multipath group Public Network Deployment

multipath group

multipath group

(Optional)

RAID device name Disk Array
Common Well-known (IPv4/IPv6/both) address Public Network Deployment

to both

Configuring HA on EMS systems for Migration
Configuring HA on Active System for Migration

$ sqlplus /nolog
SQL> startup
SQL> exit

4.
# ./configureHA

information.
q) quit

information.

q) quit


PSX.


information.

q) quit

functionality.
The
The
e1000g0
e1000g1
e1000g2
nxge0
nxge1

interface.

an option.

HA-PUB-GRP):


[y|n]:n
or
10.54.5.32) : 10.54.5.32

Setup.

10.54.5.34
Enter.




[y|n]:
or
Alives.
and press Enter.
You entered:




31.
You entered...
User Name: "oracle"
Group Name: "dba"


(default:)...



system startup.

q) quit

created...default:
/export/home/oracle


Testing scp



(default: no) [y,n]
47.


current hostname.

Configuring HA on Standby System for Migration
Configuring HA on Active System for Migration" with the following differences:
In " step 1", ensure that the database instance is stopped.




Post-configure HA Tasks
Step Number Tasks
See Checking Interface Configuration and Routing Table for Netra T5220-HA Setup.
Associate the new Insight IP with the nodes. For information, see Associating the Nodes-HA Setup.
Disassociate the old Insight IP from the nodes. For information, see Disassociating the Nodes-HA Setup.

1. Login to Insight
a. SSH Port
b. Login (CLI)
c. Password (CLI)
Upgrading from Insight EMS V09.02.00 to V09.03.00 Software Release

For more information about upgrading, refer the section Upgrading Insight High Availability.
If you are migrating from pre-9.0.0 Release or from 9.2.0 release to 9.3.0 then you must first import the
migration files to 9.2.0 and then upgrade from 9.2.0 to 9.3.0.
If you are migrating from 9.2.1 release to 9.3.0 then you must first upgrade to 9.3.0 and then import the
migration files to 9.3.0 release.
Checking Interface Configuration and Routing Table after Configuring HA
Example Details

192.168.5.1.
Procedure
setup.
ifconfig -a


1
index 2
10.10.222.255
ether 0:14:4f:4f:c0:35
10.10.222.255
ether 0:14:4f:4f:c0:36
nxge0:1:
1500 index 29
10.10.222.255
ether 0:14:4f:4f:c0:37
10.10.222.255
ether 0:14:4f:42:64:8c
e1000g1:1:
1500 index 28
10.10.222.255
ether 0:14:4f:42:64:8e
netstat -rn

Routing Table: IPv4
----------------- -------------- ----- ----- ---- ----------
192.168.5.0 192.168.5.1 U 1 46522 nxge1
192.168.6.0 192.168.6.1 U 1 5585 e1000g2
10.10.222.0 10.10.222.30 U 1 284 e1000g1
10.10.222.0 10.10.222.37 U 1 23 nxge0
10.10.222.0 10.10.222.30 U 1 0 e1000g1:1
10.10.222.0 10.10.222.30 U 1 0 nxge0:1
224.0.0.0 10.10.222.31 U 1 0 e1000g0
default 10.10.222.1 UG 1 174989
127.0.0.1 127.0.0.1 UH 33100429493 lo0
ILOM Configuration on the Netra T5220 for HA Setup
Overview
Overview
Prerequisite
the SP interface.


of the
Parameter

system console.
system.
RUNNING state.
process.

power outage.
PROM card.

sc> logout
Ok> #.
"sc>"
sc> poweroff
sc> poweron
sc> console
>"
-> reset /SP
6.

6. Enter y.
7. Press Enter.
Creating user...


Prerequisite

Requirements.

button.
set:
Verbosity: Normal
Level: Min
Update Mode: Normal
set:
Boot Timeout: 600
list.


2. Press Enter.
-> ls /SP/network
the SP Interface.
2. Press Enter.
-> cd /SP/network

7.

-> ls
Performing Post-Upgrade Tasks on HA Solaris
This section contains post-installation/post-upgrade tasks that you may need to perform.
For enabling licensing for devices in EMS, please refer to the “License Manager” section in the Insight User
Guide.
Task Purpose
Reattaching Slave Disk to the Mirror-HA Solaris If you have previously detached disk mirrors before upgrade, then
Reattach Disk Mirrors to re-establish the disk mirroring.
Or
Or
Enabling Disk Mirroring-HA Solaris
If you have never setup disk mirroring then enable disk mirroring.
Setting IBM RAID Trap destination Perform this task to set IBM RAID Trap destination.
SNMP Management Agent Configuration for HA Perform this task if you are installing SNMP and need to configure the
Setup SNMP Management Agent.
MPXIO from T5220 to IBM DS3524 Disk Arrays Activates multipathing from T5220 to IBM DS3524 Disk Arrays.

Checking Database Software Shared Memory Perform this task if you upgraded your Sonus application by using the
Settings for HA Setup Sonus Salesforce Customer Portal.
Setting the Location of Core Dump File for HA Perform this task to set the core dump file location.
Setup
Synchronizing with the NTP Server-HA Solaris Perform this task to synchronize the NTP server.
Online Library Installation or Updates-HA Setup Perform this task to install the documentation.
Clearing Client Browser Cache After a Software Perform this task on the client after an Insight upgrade.
Upgrade-HA Solaris
Netra T5220-Specific NVRAM Settings-HA Perform this task after any upgrade. This sets the NVRAM variables to
Setup the correct values.
Enabling SSH-HA Solaris Perform this task if you are using SSH for communication between the
Insight server and the PSX, SGX, and DSI.
Configuring TCP Wrappers-Aware Services-HA Perform this task if you need to allow access to TCP Wrappers-aware
Solaris services such as SSH and NFS.
Enabling Hardware Traps-HA Solaris Perform this task to enable the hardware traps.
SSL Certificate Installation Procedure Perform this task if you need to support HTTPS in a production
environment.
Enabling Users to Create cron Jobs-HA Solaris Perform this task if you need to allow users to create cron jobs.
Enabling Users to Create at Jobs-HA Solaris Perform this task if you need to allow users to create at jobs.
Upgrades-HA Solaris V07.01.01, V07.01.02, V07.02.01, V07.02.02, V07.02.03 and you want
to change any of the settings from the default of 4 weeks.
Licenses for Enabling Insight API, Insight CLI, Contact your Sonus representative to obtain software licenses.
SMS API, SGX API, Lawful Intercept
Provisioning API, and Traffic Manager-HA
Solaris
Configuring Multiple Network Interfaces-HA Perform this task after an installation if the Insight server uses multiple
Solaris network interfaces.
Deploying LNP Adaptor-HA Solaris Perform the task to deploy LNP Adaptor.
Enabling Mailx-HA Solaris Perform this task to enable mailx.
Disabling unused EMS API versions-HA Solaris Perform this task to save memory and avoid application failure.
Enabling or Disabling HTTP access on the EMS Perform the task to enable and disable HTTP access to EMS server.
HA server
Configuring the Timezone on HA Solaris Perform this task to configure the Timezone.

Checking Database Software Shared Memory Settings for HA Setup
# init 6
Clearing Client Browser Cache After a Software Upgrade-HA Solaris

displayed.

2. Select Java.
Configuring Multiple Network Interfaces-HA Solaris

#
#
127.0.0.1 localhost
Configuring TCP Wrappers-Aware Services-HA Solaris

and NFS.
/etc/hosts.allow
/etc/hosts.deny
sshd: LOCAL
to
sshd: ALL
ALL: ALL
to
#ALL: ALL
following command:
Configuring the Timezone on HA Solaris

2.

Example:
# TZ=US/Pacific
einfo.
Caution
LC_MESSAGES=C
# reboot
Deploying LNP Adaptor-HA Solaris


Disabling unused EMS API versions-HA Solaris

CAUTION

configuration.
Enabling Hardware Traps-HA Solaris


1.
# ./HwTrapGen.sh

Enabling Mailx-HA Solaris

Prerequisite



pkgadd -d . all
Enabling Mailx
# vi /etc/hosts
#
#
:: 1localhost
127.0.0.1 localhost
cd /etc/mail/

# vi sendmail.cf



Enabling or Disabling HTTP access on the EMS HA server

Enabling HTTP access on the EMS HA Server
The following section describes the procedure to enable HTTP access to the EMS HA server:
1. Stop EMS on HA server - standby.

2. Stop EMS on HA server - active.
3. Enable the HTTP access on HA server - active. Execute the following command:
# ./enableHTTP.sh
4. Enable the HTTP access on HA server - standby. Execute the following command:
# ./enableHTTP.sh
5.

5. Start EMS on active server as user insight.
6. Start EMS on standby server as user insight.
Disabling HTTP access on the EMS HA Server
Perform the following procedure to disable HTTP access to the EMS HA server:

3. Disable the HTTP access on HA server - active. Execute the following command:
# ./disableHTTP.sh
4. Disable the HTTP access on HA server - standby. Execute the following command:
# ./disableHTTP.sh

Enabling SSH-HA Solaris

File Copy.
# cd /etc/ssh

Change:

3.
to
Change:
PermitRootLogin no
to
PermitRootLogin yes

5. Perform Configuring TCP Wrappers-Aware Services-HA Solaris.

Enabling Users to Create at Jobs-HA Solaris

Enabling Users to Create cron Jobs-HA Solaris

Forcing Network Interface Configuration Using Scripts-HA Setup

Example


subsequent NIC.
For the same example, the contents of the script may also read as follows:
ndd -set /dev/bge0 adv_100T4_cap 0

ndd -set /dev/bge0 adv_100fdx_cap 1
ndd -set /dev/bge0 adv_100hdx_cap 0
ndd -set /dev/bge0 adv_autoneg_cap 0
The above block repeats for each NIC presented in the system (where the ' /dev/bge0' value increases for each
subsequent NIC).
Intercept Provisioning API, and Traffic Manager-HA Solaris
The modules are:
Insight CLI
Insight API
Insight SMS API
Insight SGX API

MPXIO from T5220 to IBM DS3524 Disk Arrays

Multipath Input/Output (MPXIO) to IBM DS3524 helps array redundancy in affected deployments. MPXIO enables
fault tolerance to the array, such that applications on the host remains unaffected even if a single controller path
fails.
Activation of MPXIO connectivity to IBM Array is explained in the following procedure:
Prerequisites
Ensure that:
IBM Array product ID must be 1814.

The RAID is not mounted by executing the following command:
# df -h|grep raid
For an HA pair with the active system in service, the following steps has to be performed first on the standby node.
Perform the following procedure to activate multipathing from T5220 to IBM DS3524 Disk Arrays:
This procedure has to be followed only during maintenance period as it affects the systems service.
1. Check if MPXIO is enabled on the standby server by executing the following command:
# stmsboot -L
stmsboot: MPxIO is not enabled
2. Run the following command to enable multi-pathing to fiber channel devices with Solaris. This command also
updates /etc/vfstab for environments where IBM Array devices are mounted at boot time.
# stmsboot -D fp -eChecking mpxio status for driver fp

WARNING: This operation will require a reboot.
Do you want to continue ? [y/n] (default: y) y
The changes will come into effect after rebooting the system.
Reboot the system now ? [y/n] (default: y) y
updating /platform/sun4v/boot_archive
15 0 records in
15 0 records out
System reboots at this point, use console to reset or power cycle if the system hangs for more than 5
minutes.
Also, reboot when prompted. If the system stops in maintenance mode, login and run the following command
to force a second reboot.

init 6
3. Run the following command to validate if multi-pathing is enabled. All the multi-pathed devices gets listed.
# stmsboot -L
non-STMS device name STMS device name
------------------------------------------------------------------
/dev/rdsk/c3t2d0 /dev/rdsk/c4t60080E50001C2FCE0000250F4FFFBE03d0
The “STMS” device name is used exclusively for affected devices once multi-pathing is enabled.
4. Edit /export/home/ems/conf/HA/haConfiguration to reflect new block and raw device name, as

given by the stmsboot -L command.
That is, change the value of RaidBlockDeviceName to /dev/dsk/
c4t60080E50001C2FCE0000250F4FFFBE03d0s6
and RaidCharacterDeviceName to /dev/rdsk/ c4t60080E50001C2FCE0000250F4FFFBE03d0s6
(“s6” is added to the multi-path device name to match the original device's “s6” disk size)
5. Perform a manual Failover to convert the Active to Standby and perform steps 1-4 for new standby server.
For information on HA manual Failover, see "HA Manual Failover".
Netra T5220-Specific NVRAM Settings-HA Setup


eprom verbosity=min
Online Library Installation or Updates-HA Setup

# ./docsInstall.sh
Performance Data Retention Settings for Upgrades-HA Solaris

Setting IBM RAID Trap destination

To receive IBM traps on Insight EMS, execute the following command:
For example:

Setting the Location of Core Dump File for HA Setup
system.
dumpadm


Directory Name".



3.

SNMP Management Agent Configuration for HA Setup

documentation.

3.
configuration file:
authtrapenable 1
agentaddress <port>
line would appear:
Continue to Manually Starting and Stopping the SNMP Agent.

Synchronizing with the NTP Server-HA Solaris

Server IP address:
multicast 224.0.1.1
with
scvadm disable ntp

scvadm enable ntp
Managing Security Settings of Insight HA on Solaris Platform

Enabling RPC processes on EMS HA Server
Disabling the RPC processes on EMS HA Server
To enable, disable or for checking the current state of RPC processes on EMS High Availability (HA) Active and
Standby System, refer the following sections:
Enabing RPC processes on EMS HA Server

Disabling RPC processes on EMS HA Server
Checking the current state of RPC processes on EMS HA Server
To enable RPC process on EMS server, execute the following steps on both active and standby systems:
1. Change the directory to <BASEDIR>/conf/security directory by executing the following command on

both active and standby systems:
#cd <BASEDIR>/conf/security
2. Enable the RPC processes, by executing the ./configureRPC.sh start command on both active and
standby systems:
starting the RPC
Starting rpcbind:

To disable RPC process on EMS server, execute the following steps on both active and standby systems:

active and standby systems:
2. Disable the RPC processes, by executing the ./configureRPC.sh stop command on active and
standby systems:
Stopping the RPC
Stopping rpcbind:
To check for the status of RPC processes, execute the following steps on both active and standby systems:

2. Check the status of RPC processes, by executing the ./configureRPC.sh status command on active
and standby systems:
#cd <BASEDIR>/bin
2. Enable the RPC processes, by executing the ./configureRPC.sh start command:

starting the RPC
Starting rpcbind:
#cd <BASEDIR>/bin
2. Disable the RPC processes, by executing the ./configureRPC.sh stop command:
Stopping the RPC
Stopping rpcbind:
#cd <BASEDIR>/bin
2. Check the status of RPC processes, by executing the ./configureRPC.sh status command:

The Insight Element Management System Software Installation and Upgrade for Disaster Recovery on Solaris
provides detailed instructions concerning the installation and upgrade of the Insight software package and other
software packages required for its operation.

Table of Contents
Introduction to EMS Disaster Recovery (Solaris)
Insight HA Configuration for EMS DR
Upgrading Insight Application Server for EMS DR
Setting up DR with No HA (Standalone) Systems
Setting up DR with HA Source and HA Target
Setting up DR with an HA source and non-HA Target
Upgrading Insight EMS DR
Managing Insight Account Names and Passwords-DR Solaris
Configuring IPv6 on DR Solaris
Common Administrative Tasks-DR Solaris
Upgrading StorageTek Firmware for DR Setup
ILOM Configuration on the Netra T5220 for DR Setup
Performing Post-installation or Upgrade Tasks on DR System
Migrating Insight Standalone 240 or 440 to a Netra 5220 for DR Setup
Migrating Insight High Availability 240/440 to Netra T5220s for DR Setup
Migrating From Storage Tek RAID to IBM RAID on T5220-DR Setup
Managing Security Settings of Insight DR on Solaris Platform
Introduction to EMS Disaster Recovery (Solaris)
This section gives an overview of Insight Element Management System and provides information about hardware
requirements.
Overview on EMS

Terminology
The following term is used throughout this chapter:
<ORACLE_BASE> — Represents the base directory of Oracle. The default is /export/home/oracle.
EMS Disaster Recovery
The DR solution for Insight EMS provides a method of deploying an additional Insight EMS system in a location

geographically separate from your primary Insight for use in the event your primary (source) Insight system
becomes disabled. Through the use of a database replication mechanism, the remote (target) system receives
periodic updates from the source (production) system, keeping the performance monitoring data and managed node
information synchronized.
The Insight EMS application as a whole is not running on the target system. However, the target system does
receive the same traps that are received by the source system. The target system cannot be used as a functioning
EMS until you switchover from source to target or failover from the source to the target.
For the DR setup, if the ems.keystore password is changed on one EMS (either source / target), then it
needs to be manually changed on the other EMS (either source / target). If it is not changed, the other EMS
will not be able to open the ems.keystore at all and all SSL connections will fail. In other words, the
ems.keystore passwords must be kept the same on both EMS (source and target) at all times.
Two-Disk Database Support
The Insight DR solution is supported for one-disk or two-disk database configurations, but the source and the target
systems must have the same database configuration when they are both non-HA. (Netra T5220s always have the
two-disk database configuration).
If an HA system is used as the source or target, the database disk configuration of the primary does not need to
match that of the target.
Data Guard Configuration
The Sonus EMS DR solution uses Data Guard, employing a Physical standby database with Maximum performance
protection mode.
The Physical standby database (on the target system) is an identical copy of the primary database (source system
database). The Physical standby database has on-disk database structures that are identical to the primary
database on a block-for-block basis. The database schema, including indexes, are the same. A physical standby
database is kept synchronized with the primary database by recovering the redo data received from the primary
database.
The Maximum performance protection mode provides the highest level of data protection that is possible without
affecting the performance of the primary database. This is accomplished by allowing a transaction to commit as
soon as the redo data needed to recover that transaction is written to the local online redo log. The primary
database’s redo data stream is also written to the standby database, but that redo stream is written asynchronously
with respect to the commitment of the transactions that create the redo data.
Switchover
A switchover is a planned role reversal between the production database and the standby database to avoid
downtime during scheduled maintenance on the production system or to test readiness for future role transitions. A
switchover guarantees no data loss. During a switchover, the production database and source system transition to a
standby role, and the standby database and target system transition to the production role. See the procedures in
Common Administrative Tasks-DR Solaris.
Failover
A manual failover is performed when the production database fails and the standby database and target system are
transitioned to take over the production role, allowing business operations to continue. The user must run the
failover procedure in order for a failover to take place.

Converting a DR System to Two Non-DR Systems
You can convert a DR system to two non-DR systems. Replication will no longer take place, and each Insight
system will act as a standalone system. The two standalone systems should not be used to concurrently manage
the same devices. See the procedures in Common Administrative Tasks-DR Solaris.
RMAN Backup
The Sonus EMS DR solution uses the RMAN DUPLICATE command to create a physical standby database.
There are several advantages to using RMAN to create a standby database:
RMAN creates standby databases using backups of the primary database, restoring data files to the standby
site from backups. Thus, the primary database is not affected during the creation of standby database.
RMAN automates renaming of files or directory structures.
RMAN restores archived redo log files from backups and performs recovery to catch up the standby database
to the primary database.
The following rman scripts create the Physical standby database; the scripts are run on the source database
(primary database).
rman_standby_backup.ksh
rman_restore_standby.ksh
Ignore the following error messages while running the rman_restore_standby.ksh script:
Ignore the error code RMAN-00569 if available in log /export/home/oracle/orarepl/SIDB/logs/co

nf/error.lis.
After the rman_standby_backup.ksh is run, all the backup files and archive log files from the source database
need to be copied to the same file location on the target database.
Replication Traps
Traps are generated to indicate problems that exist with the DR processes. See the release notes for details.
DR-related traps will not be automatically cleared; they must be manually cleared. (This is because the traps could
be used to trace any DR problems if they exist.)
During DR setup when the target is being setup, the source will send out traps indicating that the target is not
available. These traps can be ignored.
Temporary Archive Files
Several backup archive files will appear in the following directory on the source and target systems after DR is
configured:
<ORACLE_BASE>/orarepl/<ORACLE_SID>/logs/monitor
These files will be removed after one day.

Registration of Source and Target Nodes
Users need to register the DR source and DR target as separate Insight nodes in the Node Administration screen.
This ensures that after a DR switchover, the Application Management settings for the original DR source are
available under the new DR source (original target).
Restarting Source and Target Databases
If the database on the source goes down and is restarted, run the start_standby_database.ksh script on the
target. This script stops and restarts the database on the target, which prevents the target database from being out
of sync. This script is located in <ORACLE_BASE>/orarepl/<ORACLE_SID>/scripts/conf.
Disaster Recovery Scripts and Files Overview
There are several scripts with which you should be familiar when deploying an Insight DR solution. The scripts and
their uses are:
configureDR — typically used during initial configuration of the DR systems to assign operational mode
(source or target) and setup database replication. This script is located in
/export/home/ems/conf/DR.
convert — used to convert the operational mode of an existing DR system to either source, target, or
standalone. This script is located in /export/home/ems/conf/DR.
sonusEms start — if run on the source system, this script starts Insight (including FM) and process
monitoring. If run on the target system, this script starts the FM process and process monitoring.
sonusEms stop — if run on the source system, this script stops Insight and process monitoring. If run on
the target system, this scripts stops process monitoring.
configureDR.log — the log file for configureDR, located in /export/home/ems/logs
convert.log — the log file for convert, located in /export/home/ems/logs
start_standby_database.ksh — used on the target system after the database on the source goes down
and is restarted. This script stops and restarts the database on the target, which prevents the target database
from being out of sync. This script is located in
<ORACLE_BASE>/orarepl/<ORACLE_SID>/scripts/conf.
Hardware Requirements for EMS DR configuration
The following table, provides the minimum supported platforms required for EMS Disaster Recovery (DR):

Table 101: Hardware Configuration for EMS DR.
Platform Configuration
Netra T5220 HA 4 x 1.2 GHz CPU, 16 GB memory, 4 x 300 GB hard
(fourdrive) drives, Quad GigENET Card,
4 x 10/100/1000 Ethernet Ports, Fibre Channel Card
Host Interface Four 8 Gb/s FC ports per controller
Disk Drives 9 x 300 GB 10K 2.5-inch HDD installed in slots 1-9.
Supported 5 and 9 disk configuration.
Sonus recommends 5 disk configuration.
RAID RAID-1+0
Firmware Controller 07.83.27.00
07.77.20.00
IBM DS Storage Manager Host Software Version: 10.83.x5.23 (Solaris)
you do not collect performance data extensively or frequently, then the platform’s ability to support managed devices

root (/) 5GB
var (/) 4GB
opt (/) 5GB
SWAP (/swap) 16GB
(reserved) 0.15GB
(reserved) 0.15GB
Disk Mirroring
Disk 1 <-> Disk 3

Disk 2 <-> Disk 4
UPS Recommendations


Management (ILOM)
Lsof 4.8
Sun Cluster 3.2U2
Appware version 07.77.20.00, 07.83.27.00
Java Server version 1.7.0_72
Java Client version 1.7.0_72, 1.8.0_45 (*)
plugin.
Insight HA Configuration for EMS DR
This section describes, how to configure an Insight HA system on two Netra T5220 servers.
Topics include:
Hardware Requirements and Other Restrictions for HA DR
High Level Task Sequence for Configuring HA for EMS DR
Setup and Configure Netra T5220 platforms with RAID Disk Arrays for EMS HA DR

Netra T5220 Disk Labeling and File System Creation for the RAID Disk Array for EMS HA DR
Private Network Setup for EMS HA DR
Public Network Setup for EMS HA DR
Configuring HA on EMS HA DR systems
Post-HA Configuration Tasks for EMS HA DR
Checking Interface Configuration and Routing Table for Netra T5220 for EMS HA DR
Hardware Requirements and Other Restrictions for HA DR

Hardware
Quad GigENET PCI-E card installed on each Netra T5220

Either one of the following Storage Arrays:
StorageTek 2450 Array with four fiber-optic cables
Restrictions
request.
High Level Task Sequence for Configuring HA for EMS DR

This section and subsequent steps are used if you want to setup HA on existing Solaris Standalone servers. For
example, if you already have to 2 Insight EMS Standalone servers with a prior release earlier than V09.02.00,
upgrade both the EMS Solaris SA servers using Sonus Salesforce upgrade method to V09.03.00. After upgrading
both the servers to V09.03.00, if you want to setup HA between the two Standalone servers, perform the following
steps, to configure both the servers in HA deployment. One of the servers perform the role of primary (active) while
the other servers performs the role of non-primary (standby).
1. Setup and Configure Netra T5220 platforms with RAID Disk Arrays for EMS HA DR (perform on both the
active and standby EMS systems)
a. Setting Up and Configuring Netra T5220 Systems with IBM DS3524 Storage System for EMS HA DR
b. Setting Up and Configuring Netra T5220 Systems with StorageTek 2540 Disk Array for EMS HA DR
2. Netra T5220 Disk Labeling and File System Creation for the RAID Disk Array for EMS HA DR
3. Private Network Setup for EMS HA DR
4. Public Network Setup for EMS HA DR
5.

5. Configuring HA on EMS HA DR systems
6. Checking Interface Configuration and Routing Table for Netra T5220 for EMS HA DR (verify on both the
active and standby EMS systems).
Setup and Configure Netra T5220 platforms with RAID Disk Arrays for EMS
HA DR
This section provides information on configuring Netra 5220 systems with RAID disk arrays for EMS HA DR.
Sonus supports two RAID array options, they are:
Setting Up and Configuring Netra T5220 Systems with IBM DS3524 Storage System for EMS HA DR Setting Up
and Configuring Netra T5220 Systems with StorageTek 2540 Disk Array for EMS HA DR
EMS HA DR
This section provides information on setting up and configuring Netra 5220 systems wit IBM DS3524 array.
Topics include:

T5220 systems.



archive...
..
.....
......
....
.....

4Gbps, and 2Gbps
enclosures

servers.
servers.
export DISPLAY
echo $DISPLAY
# ./SMclient

Management window.
discovery.
for the password.
192.168.128.101 Port 1
192.168.129.101 Port 2
addresses.

configuration.
For example,

Unnamed 10.54.58.94 10.54.58.95

For example,
EMSIBMRAID\";"
# SMcli -i -d
# SMcli -i -d
EMSIBMRAID 10.54.58.109 10.54.58.110


7.

1. for 146GB
2. for 300GB

1. for 136GB
2. for 270GB
9. Enter the RAID password that you had entered on step 9 of the Configuring IBM DS3524 Storage Subsystem
Controller IP Address section when the following is prompted and press Enter.
For example, 10.54.58.109.

Enter.
SONSemsarray )
EMSIBMRAID
....
...
...
some time
#

12.

12. Reboot EMS.
# reboot -- -r
Setting Up and Configuring Netra T5220 Systems with StorageTek 2540 Disk Array for
EMS HA DR
This section provides information on setting up and configuring Netra 5220 systems with StorageTek 2540 array.
Topics include:

StorageTek 2540RAID Disk Array Configuration on Insight EMS Servers
or nxge3.


5.

controllers.

==============================
Q) Quit Menu
Enter Selection:
Enter 2.
Enable IPv4 (Y/N)?
Enter Y.
Enter N.

9.



Subnet Mask : 255.255.255.0

StorageTek 2540RAID Disk Array Configuration on Insight EMS Servers


2.

SONSemsarray.

Netra T5220 Disk Labeling and File System Creation for the RAID Disk Array
for EMS HA DR
Active System
1. Log on as root.
# format

ssd@w202500a0b85a427e,1f
ssd@w202400a0b85a427e,0
ssd@w202400a0b85a427e,1f


1060 cyl 53502 alt 2 hd 512 sec 64>

number):
Enter the number that corresponds to the disk c2t2d0 or c2t4d0.
For selecting the disk, make sure that the drive controllers for the primary and the standby servers
are the same.
selecting c2t2d0
[disk formatted]
c2t4d0s6 Enter yes.
5.

Where <partition> is the designator for your disk and disk slice. The disk was displayed in Step 4. The disk
slice is s6. For the example shown in Step 4, you would enter:

/export/raid:

total 16
lost+found
# df -h|grep raid
# df -h|grep raid
becomes active.
Standby System
system.


# format
ssd@w203400a0b867dc82,0
64>
ssd@w203400a0b867dc82,1f
ssd@w203300a0b867dc82,0
64>


64>

64>

1060 cyl 53502 alt 2 hd 512 sec 64>

number):
If you are using IBM DS3524 RAID, enter the disk name of the Standby System.
are the same.
When the format command is run, it does not prompt for labeling because the disk has already been
labeled when you configured the RAID disk on the active Netra.
/export/raid:

a.
disk slice is s6. If the value shown in Step 3 was c2t4d0, you would enter:
total 16
# df -h|grep raid
g.

# df -h| grep raid
becomes active.
Private Network Setup for EMS HA DR

failure).
systems.
Procedure
systems.

a.
b. Record the value of each IP address; you will need these values when running the configureHA
script.
interfaces on the system. Depending on the private network interface IP address, specify the Network
number and subnet mask of the respective private network interface.
subnet mask in /etc/netmasks file as:
192.168.5.0 255.255.255.0
(This example considers e1000g2 as the private interface and 255.255.255.0 as the netmask)

e. Restart the network services svcadm

System Item Value

Public Network Setup for EMS HA DR


Prerequisite
configureHA script.
System Item Value
Requirements
allowed.
Procedure
2. Log on as root.

3.

Caution

System Item Value

Configuring HA on EMS HA DR systems

for the first time.
Topics include:
Prerequisites
Running the configureHA Script

Running haMigrateFiles.sh Script
Prerequisites
system information. Table System Information Work Sheet lists the information you will need, and the procedures in
which these values were assigned. You can enter your values into the table and use it as a reference when you run
configureHA.
Performed the first five items in High Level Task Sequence for Configuring HA


assigned

(Optional)

multipath group

multipath group

RAID device name for EMS HA DR

multipath group

multipath group

(Optional)

RAID device name for EMS HA DR

to both

Running the configureHA Script
haConfiguration file in the /export/home/ems/conf/HAdirectory.

$ sqlplus /nolog
SQL> startup
SQL> exit
in the section Netra T5220 Disk Labeling and File System Creation for the RAID Disk Array for EMS HA DR .

4.
# ./configureHA


information.
q) quit
Type 2 and press Enter to enter the OAM IP addresses. In OAM IP configuration, the OAM IP address uses
PSX proxy mode.


PSX.



functionality.
The
The
e1000g0
e1000g1
e1000g2
nxge0
nxge1

interface.
an option.
16.


HA-PUB-GRP):


[y|n]:

10.54.5.32) : 10.54.5.32
What is the test IPV6 address for the primary LAN interface :
NOTE: The configureHA script provides the user to configure the HA in IPv4 or IPv6.
If you want to configure an IPv6 HA Setup, please leave all the IPv4 addresses blank.
If you want to configure an IPv4 HA setup, please follow the following steps:
INVALID IPv6 address format.
Do you want to stop entering this IP address? (default: no) [y,n] y
a. Type the IP test address for the primary interface for the multipath group, and press Enter.
You would have established the primary interface for the multipath group in Public Network
Setup.
What is the test IPV6 address for the secondary LAN interface :

20.

10.54.5.34
What is the well-known IPV6 address on the LAN :

What is the "dummy" IPV6 address for the secondary interface :

What is the IPV6 reachability address :
Enter.


26.


[y|n]:

Alives.
Alives
and press Enter.
You entered:



You entered...
User Name: "oracle"
Group Name: "dba"


32.
for the RAID Disk Array for EMS HA DR and press Enter.
System Creation for the RAID Disk Array for EMS HA DR and press Enter.

(default:)...



system startup.

37.

q) quit

created...default:
/export/home/oracle



Testing scp



(default: no) [y,n]

current hostname.
48.

servers. For information on configuring mailx, see Enabling Mailx-DR Solaris.
Perform the following procedure on the Standby system.
1. Ensure that the database instance is stopped.

Log on to Insight as root.
$ sqlplus /nolog
SQL> startup
SQL> exit

3.
in the section Netra T5220 Disk Labeling and File System Creation for the RAID Disk Array for EMS HA DR .
# ./configureHA

Type 1 and press Enter to configure system as standby.
Enter s and the system displays the following message:
This system will be configured as an Standby system.


9.





functionality.
The
The
e1000g0
e1000g1
e1000g2
nxge0
nxge1


interface.
an option.

HA-PUB-GRP):


[y|n]:

10.54.5.32) : 10.54.5.32

a. NOTE: You would have established the primary interface for the multipath group in Public Network
Setup.

10.54.5.34


Enter.



[y|n]:

Alives.
Alives
and press Enter.

You entered:



You entered...
User Name: "oracle"
Group Name: "dba"

for the RAID Disk Array for EMS HA DR and press Enter.
System Creation for the RAID Disk Array for EMS HA DR and press Enter.

(default:)...
a.




system startup.

q) quit
array.
You must choose a different operation than you chose for the active system. If you chose item 1 for the active
system, you must choose item 2 for the standby system.
Press Enter after making your selection. The system then displays several status messages. If necessary,
you can enter q to return to the main menu.

created...default:

/export/home/oracle
chmod 775 /export/home/oracle/admin/SIDB/udump

mkdir /export/home/oracle/admin/SIDB/arch
chown oracle:dba /export/home/oracle/admin/SIDB/arch
chmod 775 /export/home/oracle/admin/SIDB/arch
rm -rf /tmp/oraclebasevalue


Perform the steps mentioned in Running haMigrationFiles.sh files.
After configuring the HA system as standby, release the resources:
Only after the resources are released, launch the EMS in active mode and subsequently in standby mode.
Testing scp



(default: no) [y,n]

current hostname.


servers. For information on configuring mailx, see Enabling Mailx.
52. After you run the configureHA script on the active and standby systems, go to Post-HAconfigure Tasks.
Running haMigrateFiles.sh Script
Perform the following procedure to run the haMigrateFiles.sh:
1. Log in as user root and enter the following command to start the haMigrateFiles script.
This script creates /export/raid/sonusEms/data and /export/raid/sonusEms/logs folders on

the RAID mounted point and creates the links /export/home/ems/weblogic/sonusEms/dataRaid and
/export/home/ems/weblogic/sonusEms/logsRaid. These links point to
/export/raid/sonusEms/data and /export/raid/sonusEms/logs respectively.
1. Migrate Inventory, Network Health, Network Fault, Topology and Trunk Group Reports
2. Migrate PM csv files
3. Migrate User Audit Log files
4. Migrate All back to Standalone
q. Quit
3. Select 1 from the menu
The following options appear:
1) Move the Report Archives to the RAID.
2) Point this system to use the Report Archives already on the RAID.
q) quit
4. Select 1 from the list of options.
This step moves the existing Report Archives to the RAID and updates the configuration to point to
/export/home/ems/weblogic/sonusEms/dataRaid.
5.

q) quit
6. Select 2 from the menu. The following options are listed:
1) Move the PM CSV files to the RAID.
2) Point this system to use the PM CSV files already on the RAID.
q) quit
7. Select 1 from the options. This step moves the existing PM CSV files to the RAID and updates the
configuration to point to /export/home/ems/weblogic/sonusEms/dataRaid.
Creating /export/home/ems/weblogic/sonusEms/dataRaid/pm_archive.
cp -R /export/home/ems/weblogic/sonusEms/data/pm_archive/scp-tmp-dir
/export/home/ems/weblogic/sonusEms/dataRaid/pm_archive.
Enter dbimpl.
What is the sqlplus passwd of SIDB? (default: dbimpl) [dbimpl]::
Enter dbimpl.
q) quit
1) Move the User Audit Log files to the RAID.
2) Point this system to use the User Audit Log files already on the RAID.
q) quit
12. Select 1 from the list of options. This step moves the existing UserAuditLog files to the RAID and updates the
configuration to point to /export/home/ems/weblogic/sonusEms/logsRaid.
13.

Enter dbimpl.
What is the sqlplus passwd of SIDB? (default: dbimpl) [dbimpl]:
Enter dbimpl.
14. Select q from the main menu to generate the High Availability Migration Main Menu.
The following options are listed:
q) quit
15. Select q to quit.
OAM stands for Operations And Management. OAM IP address is used by the users to access all EMS northbound
interfaces like GUI, CLI, and API. A user can have two different networks for OAM and signaling. In this scenario,
EMS can act as a proxy for PSX to enable the PSX manager GUI to talk to PSX. In a standalone EMS deployment
with two different networks for OAM and signalling, the PSX manager GUI connects to the EMS through the EMS
OAM IP address, if PSX proxy mode is enabled. In case of an EMS HA deployment with PSX proxy mode enabled
and the user has two different networks for OAM and signaling, the active EMS and standby EMS have their own
respective OAM IP addresses. In that case, the PSX manager GUI will use the appropriate OAM IP of the current
active server.
Post-HA Configuration Tasks for EMS HA DR

1. Verify that the interfaces and routing table are configured correctly. See Checking Interface Configuration and
Routing Table for Netra T5220 for EMS HA DR.
2. Enable Multipath for IBM RAIDS. For more details, see MPXIO from T5220 to IBM DS3524 Disk Arrays for
DR Setup.
3. First start Insight on the active system and then on the standby system.
4. Register or update the registration of each Insight device (see Chapter 4 of the Insight EMS User Guide).
Checking Interface Configuration and Routing Table for Netra T5220 for EMS
HA DR
Example Details


192.168.5.1.
Procedure
setup.
ifconfig -a

1
index 2
10.10.222.255
ether 0:14:4f:4f:c0:35
10.10.222.255
ether 0:14:4f:4f:c0:36
nxge0:1:
1500 index 29
10.10.222.255
ether 0:14:4f:4f:c0:37
10.10.222.255
ether 0:14:4f:42:64:8c
e1000g1:1:
1500 index 28
10.10.222.255
ether 0:14:4f:42:64:8e
netstat -rn

Routing Table: IPv4
----------------- -------------- ----- ----- ---- ----------
192.168.5.0 192.168.5.1 U 1 46522 nxge1
192.168.6.0 192.168.6.1 U 1 5585 e1000g2
10.10.222.0 10.10.222.30 U 1 284 e1000g1
10.10.222.0 10.10.222.37 U 1 23 nxge0
10.10.222.0 10.10.222.30 U 1 0 e1000g1:1
10.10.222.0 10.10.222.30 U 1 0 nxge0:1
224.0.0.0 10.10.222.31 U 1 0 e1000g0
default 10.10.222.1 UG 1 174989
127.0.0.1 127.0.0.1 UH 33100429493 lo0
Upgrading Insight Application Server for EMS DR

Application Server.
server B.
Before You Begin
Have a system that meets the specifications in Hardware and Software Requirements for Insight EMS DR
Deployment.
Upgrading an IAS to Solaris DR HA
Other IAS Procedures-Solaris EMS HA DR
Upgrading an IAS to Solaris DR HA



uname -v
Generic_150400-20
the remote system.
started.

Other IAS Procedures-Solaris EMS HA DR


IAS
following:

Prev IAS version:
Prev Agent version:
Prev JBoss version:
Prev JRE version:
IPv4/IPv6 address.
following:

# cd <IAS_BASE>/bin
# ./enableHTTP.sh

[y,n] y
Stopping IAS...
IAS Server stopped.


# cd <IAS_BASE>/bin
Stopping IAS...
IAS Server stopped.

Setting up DR with No HA (Standalone) Systems
This section describes how to setup DR, and configure an Insight DR system with No HA standalone systems.
The Insight DR solution is supported for one-disk or two-disk database configurations, but the primary and
the target systems must have the same database configuration when they are both non-HA. (Netra T5220s
always have the two-disk database configuration.)
This chapter contains the following sections:
Prerequisite
Overview of setting up DR With No HA (Standalone) systems
Setting up DR With No HA (Standalone) systems
Prerequisite
Before setting up DR with no HA (Standalone) systems, upgrade EMS to V09.03.00 on the systems that will be part
of the DR setup.
Overview of setting up DR With No HA (Standalone) systems
The following table gives an overview for setting up DR with No HA (Standalone) systems.
Source System Target System
Prerequisite: Upgrade EMS to V09.03.00 and start Insight. Prerequisite: Upgrade EMS to V09.03.00 and start Insight.
1. Establish and verify communication between the source and target system using the method of your choice.
2. (Start of maintenance window.)
Stop Insight.
3. Unschedule DR monitoring.

4. Run the delete_data_files.sh script available under
$ORACLE_BASE> /orarepl/$ORACLE_SID/scripts/conf
directory to delete the data files.
Stop Insight.
7. Run configureDR
8. As user oracle, create a backup of the Insight Database.
9. Create a directory with the same path name and size as created in
Step 8.
10. Run rman_standby_backup.ksh.
11. Enter a directory pathname for the location in which you will store the backup files. This is the directory that
you created in Step 8.
12. Start Insight.
(End of maintenance window.)
13. Update $ORACLE_BASE/.profile file with ORACLE_SID value

displayed in Step 7.
14. Run configureDR.
15. Copy database backup files created in Step 8 to target system.
16. Copy the files from the $ORACLE_BASE/oradata/$ORACLE_SID/arch directory to the same directory on
the target system.
17. Run rman_restore_standby.ksh
Note: See RMAN Backup for ignoring specific error messages that appear while running
rman_restore_standby.ksh script.
18. Copy the password file from source to target.
19. Run start_standby_database.ksh.
20. Run enable_primary_database.ksh
21. Run create_archivelog.ksh
22. Run sequence_num_status.ksh
23. Run create_archivelog.ksh and sequence_num_status.ksh
Check to see if the SOURCE_SEQUENCE, TARGET_ARCHIVED_SEQ, and TARGET_APPLIED_SEQ values

have all incremented.
24. Run configureDrMonitoring.
25. Run configureDrMonitoring.
26. Start Insight.

Setting up DR With No HA (Standalone) systems
Use the following procedure to configure an Insight DR deployment with a non-HA (Standalone) systems.
Before performing the below procedure, both the source and target systems must have EMS started at least once on each system.
Step System Action

(Target
or
Source)
1. Target Establish and verify communication between the source and target system using the method of your choice.
and
source
2. Target Stop Insight on the target system by executing the following command as user insight:
$ ./sonusEms stop
3. Target If this is not the first time you have attempted to configure DR, unschedule DR monitoring on the target system. As root, enter the following:
# cd /export/home/ems/conf/DR
# ./configureDrMonitoring remove
4. Target On the target system, change to user oracle, and enter the following commands to delete the data files:
$ cd $ORACLE_BASE/orarepl/$ORACLE_SID/scripts/conf
$ ./delete_data_files.sh
5. Source Stop Insight on the source system by executing the following command as user insight:
$ ./sonusEms stop
6. Source If this is not the first time you have attempted to configure DR, unschedule DR monitoring on the source system. As root, enter the following:
7. Run the configureDR script on the source system:
Source a. As root on the source system, navigate to the DR directory and run the configureDR script as follows:
# ./configureDR
Source b. The following prompt appears:
This system is currently configured as a standalone EMS system.
Will this system be part of an HA pair? (default:n) [y|Y,n|N]
Answer N.
Source c. The following prompt appears:
Is the other DR system configured as a HA system?? (default:n) [y|Y,n|N]
Answer N.

Source d. The following prompt appears:
This system can be configured in one of two modes:
a) source
b) target
Please select one of the options above (default:a) [a|b]:
Answer a.
Source e. A message appears that identifies the ORACLE_SID setting in the user oracle’s .profile file, and then the following prompt appears:
Is this the correct ORACLE_SID value for this system and for your Insight database? (default:y) [y|Y,n|N]
Answer Y.
Source f. A message appears that gives the ORACLE_SID value that will need to be set on the target system. Make a note of this value.
When prompted to confirm that you will update the setting, answer Y. (You will update the setting on the target system in Step 13.)
Source g. A message appears that identifies the IP address of the source system. Make a note of the value.
When prompted to confirm that you will use this value as the source IP address when running configureDR on the target system, answer Y. (You will enter the
source IP address in Step 14g.)
Source h. The following prompt appears:
What is the IP address of the DR Target node?
Enter the IP address of the target system.
Source i. When prompted to confirm the values you have entered, ensure that the listed values are correct and then answer Y.
Source j. The following prompt appears:
There should be a zero length file on <IP address of target system> called /tmp/sshtestfile.nnnnn
Please verify that this file does exist on the remote system.
Did the remote file get created? (default:n) [y|Y,n|N]
Ensure that the file sshtestfile.nnnnn (where nnnnn represents a number) exists on the target system.
If the file exists:
Answer Y.
When the configureDR script has finished, the following appears:
Completed successfully. Done.
If the file does not exist:
The scp command has failed. Perform the following:
(1). Ensure that the insight password has not expired.
(2). Ensure that PermitRootLogin is set to yes in the /etc/ssh/sshd_config file.
(3). Ensure that the /etc/hosts.allow file has the entry sshd: ALL
(4). Perform Step 8 again.
If the file still does not exist, contact the Sonus TAC.
8. Source On the source system, change to user oracle and create a directory that has enough space to hold a backup of the Insight database.
Make a note of this directory pathname. You will need to use this same pathname in Steps 11 and 15.
9. Target As user oracle on the target system, create a directory that has the same pathname and size as the directory you created in Step 8.

10. Source As user oracle on the source system, enter the following:
$ ./rman_standby_backup.ksh
11. Source The following prompt appears:
Enter the Backup Path for the location to which to store the backup of this systems Insight database.
Enter a directory pathname for the location in which you will store the backup files. This is the directory that you created in Step 8. Do not use a softlink.
12. Source As user insight, start Insight on the source system:
$ ./sonusEms start
After Insight has started, continue to Step 13.
13. Target As user oracle on the target system, edit the $ORACLE_BASE/.profile file so that it contains the ORACLE_SID value that was displayed in Step 7f.
After modifying the file, save it. Then execute it by using one of the following methods:
The environment variables $ORACLE_BASE, $ORACLE_HOME, and $ORACLE_SID must be set by logging in as su - oracle and
executing the script .profile. On the source system the $ORACLE_SID value is SIDB, while at the target system the $ORACLE_SID
value is SIDR.
Re-login as oracle
As k-shell, enter:
. .profile
As bash, enter:
source .profile (as bash)
14. Run the configureDR script on the target system:
Target a. As root on the target system, navigate to the DR directory and run the configureDR script as follows:
# ./configureDR
Target b. The following prompt appears:
Answer N.
Target c. The following prompt appears:
Answer N.
Target d. The following prompt appears:
a) source
b) target
Answer b.
Target e. A message appears that identifies the ORACLE_SID setting in the user oracle’s .profile file, and then the following prompt appears:
Is this the correct ORACLE_SID value the correct setting as specified when you ran ./configureDR on the DR Source
system? (default:y) [y|Y,n|N]
Verify that the ORACLE_SID value displayed is the same value that was displayed in Step 7f, then answer Y.

Target f. A message appears that identifies the IP address of the target system. When prompted to confirm that you used this value for the target system when running con
figureDR on the source system in Step 7h, answer Y.
Target g. The following prompt appears:
What is the IP address of the DR Source node?
Enter the IP address of the source system, which was displayed in Step 7g.
Target h. When prompted to confirm the values you have entered, ensure that the listed values are correct and then answer Y.
Target i. The following prompt appears:
There should be a zero length file on <IP address of source system> called /tmp/sshtestfile.nnnnn
Ensure that the file sshtestfile.nnnnn (where nnnnn represents a number) exists on the source system.
If the file exists:
Answer Y.
(2). Ensure that PermitRootLogin is set to yes in the /etc/ssh/sshd_config file).
15. Source On the source system, change to user oracle, and copy the contents from the source system directory created in Step 8 and put them in the target system directory
created in Step 9. The pathname for the directory on the source and the directory on the target must be the same.
16. Source As user oracle on the source system, copy the files from the $ORACLE_BASE/oradata/$ORACLE_SID/arch directory to the same directory on the target system.
$ ./rman_restore_standby.ksh
Enter oracle password on the Target for the sys user.
For more information, refer to “Insight Account Names and Passwords”.
Please confirm oracle password on Target for the sys user.
For more information, refer to “Insight Account Names and Passwords”.
Ignore the error code RMAN-00569 if available in log /export/home/oracle/orarepl/SIDB/logs/conf/error.lis.
18. Source On the source active system, do the following:
a. Change to user oracle.
b. Copy the password file from Source system to the target system. The file is: $ORACLE_HOME/dbs/orapw$ORACLE_SID
The $ORACLE_SID value at the Source system is SIDB and the $ORACLE_SID value at the Target system is SIDR.
For example:
scp $ORACLE_HOME/dbs/orapwSIDB oracle@<TARGET_IP>:$ORACLE_HOME/dbs/orapwSIDR

19. Target On the target system, change to user oracle, and enter the following:
$ ./start_standby_database.ksh
$ ./enable_primary_database.ksh
Steps 21, 22, and 23 verify that replication is functioning.
$ ./create_archivelog.ksh
Results spooled to /export/home/oracle/orarepl/SIDB/logs/conf/create_archivelog.log
The environment is:
ORACLE_BASE=/export/home/oracle
ORACLE_HOME=/export/home/oracle/product/10.2.0.3
ORACLE_SID=SIDB
System altered.
$ cd $ORACLE_BASE/orarepl/$ORACLE_SID/scripts/monitor
$ ./sequence_num_status.ksh
Output similar to the following appears:
SOURCE_SEQUENCE
---------------
172
TARGET_ARCHIVED_SEQ TARGET_APPLIED_SEQ
------------------- ------------------
172 171
Make a note of the SOURCE_SEQUENCE, TARGET_ARCHIVED_SEQ, and TARGET_APPLIED_SEQ values.
23. Source As user oracle on the source system, perform the following:
a. Enter the following again:
b. Enter the following again:
c. Check to see if the SOURCE_SEQUENCE, TARGET_ARCHIVED_SEQ, and TARGET_APPLIED_SEQ values have all incremented from those displayed in Step 22.
If all of the values have incremented from those displayed in Step 22, go to Step 24.
If any of the values have not incremented from those displayed in Step 22, repeat Step 23, substeps a, b, and c every few minutes until all the values have
incremented. It is not unusual for this to take 15 minutes.
If you repeat substeps a, b, and c for 15 minutes and any of the values have not incremented, contact the Sonus TAC.

24. Source As root on the source system, enter the following:
# ./configureDrMonitoring
25. Target As root on the target system, enter the following:
26. Target Start Insight on the target system by logging in as insight and executing the following commands:
$ ./sonusEms start
Setting up DR with HA Source and HA Target
This section describes how to setup an Insight DR system when the source is an HA system and the target is an HA
system.
Prerequisite
Overview of setting up DR with HA Source and HA Target
Setting Up DR with HA Source and HA Target
Prerequisite
Before setting up DR on a system with an HA source and HA target, all the systems need to have EMS V09.03.00.
Overview of setting up DR with HA Source and HA Target
The following table gives an overview for setting up DR when the source is an HA system and the target is also an
HA system.
Step HA Source Active System HA Source Standby System HA Target Active System HA Target Standby System
Prerequisite: Upgrade EMS to V09.03.00 HA system and start Insight Prerequisite: Upgrade EMS to V09.03.00 HA system and start Insight
1 Establish and verify communication between active and standby systems.
2 (Start of maintenance window)
Stop Insight.
3 Unschedule DR monitoring.
Stop Insight.

6 Run the delete_data_files.sh script
available under
$ORACLE_BASE>
/orarepl/$ORACLE_SID/scripts/conf
7 Run the delete_data_files.sh script
available under
$ORACLE_BASE>
/orarepl/$ORACLE_SID/scripts/conf
Stop Insight.
10 Run configureDR.
Stop Insight.
13 Run configureDR.
14 Create a directory to hold a backup of the Insight

database.
15 Create a directory to hold a backup of

the Insight database.


18 Run rman_standby_backup.ksh.
19 Enter directory pathname that you created in Step

14.
20 Start Insight.
(End of maintenance window)
21 Start Insight.
22 Update $ORACLE_BASE/.profile f
ile with
ORACLE_SID value displayed in Step

7.
23 Run configureDR.
24 Update $ORACLE_BASE/.profile
file with ORACLE_SID value
displayed in Step 7.

25 Run configureDR.
26 Copy the contents from the source active system

directory
created in Step 14 and to the target active system
directory created in Step 16.
27 Copy the files from the

$ORACLE_BASE/oradata/$ORACLE_SID
/arch directory to the same directory on the target
active system
28 Run rman_restore_standby.ksh
Note: See "RMAN Backup" for ignoring
specific error messages that appear
while running script
rman_restore_standby.ksh.
29 Copy the password file from source Active
system to source standby system, target
active system, and target standby system.
30 Run start_standby_database.ks
h.
31 Run enable_primary_database.ksh.
32 Run ./create_archivelog.ksh.
33 Run ./sequence_num_status.ksh
34 Run ./create_archivelog.ksh
Run ./sequence_num_status.ksh
35 Run configureDrMonitoring
36 Run configureDrMonitoring.
37 Run configureDrMonitoring
39 Start Insight.
40 Start Insight.
Setting Up DR with HA Source and HA Target

Use the following procedure to configure an Insight DR deployment with an HA source and an HA target. Before performing this procedure, both the source and target systems must have EMS
started at least once on each system.
Step System Action
1 Target Establish and verify communication between the source and target system using the method of your choice.
active and
source

2 Target Stop Insight on the target standby system by executing the following command as user insight:
standby
$ ./sonusEms stop
3 Target If this is not the first time you have attempted to configure DR, unschedule DR monitoring on the target standby system. As root, enter the following:
standby
4 Target Stop Insight on the target active system by executing the following command as user insight:
active
$ ./sonusEms stop
5 Target If this is not the first time you have attempted to configure DR, unschedule DR active on the target standby system. As root, enter the following:
active
6 Target As user oracle on the target active system, enter the following commands to delete the data files:
active
7 Target As user oracle on the target standby system, enter the following commands to delete the data files:
standby
8 Source Stop Insight on the source standby system by executing the following commands as user insight:
standby
$ ./sonusEms -d stop
Allow the database to continue running.
9 Source If this is not the first time you have attempted to configure DR, unschedule DR monitoring on the source standby system. As root, enter the following:
standby

10 Source Run the configureDR script on the source standby system:
standby
1. a. As root on the source standby system, navigate to the DR directory and run the configureDR script as follows:
# ./configureDR
b. The following prompt appears:

Confirm that this system is currently an HA Standby system? (default:y) [y|Y,n|N]
Answer Y.
c. The following prompt appears:

Answer Y.

a) source
b) target
Answer a.
e. A message appears that identifies the ORACLE_SID setting in the user oracle’s .profile file, and then the following prompt appears:
Answer Y.
f. A message appears that gives the ORACLE_SID value that will need to be set on the target system. Make a note of this value.
When prompted to confirm that you will update the setting on the target system, answer Y. (You will update the setting in Steps 22 and 24.)
g. A message appears that identifies the IP address of the source HA system. Make a note of the value.
When prompted to confirm that you will use this value as the source IP address when running configureDR on the target system, answer Y. (You will enter
the source IP address in Steps 23g and 25g.)
h. The following prompt appears:

Enter the well-known IP address of the target HA system.
i. The following prompt appears:

What is the fully qualified path of the RAID device mount point on the other DR HA system? (i.e. /export/raid)
Enter the RAID device mount point that is on the source system.
j. When prompted to confirm the values you have entered, ensure that the listed values are correct and then answer Y.
k. The following prompt appears:

If the file exists:
Answer Y.
11 Source Stop Insight on the source active system by executing the following command as user insight:
active
12 Source If this is not the first time you have attempted to configure DR, unschedule DR monitoring on the source active system. As root, enter the following:
active

13 Source Run the configureDR script on the source active system:
active
1. a. As root on the source active system, navigate to the DR directory and run the configureDR script as follows:
# ./configureDR

Confirm that this system is currently an HA Active system? (default:y) [y|Y,n|N]
Answer Y.

Answer Y.

a) source
b) target
Answer a.
Answer Y.
f. A message appears that gives the ORACLE_SID value that will need to be set on the target system. Make a note of this value.
When prompted to confirm that you will update the setting, answer Y. (You will update the setting on the target system in Steps 22 and 24.)
g. A message appears that identifies the IP address of the source HA system. Make a note of the value.
When prompted to confirm that you will use this value as the source IP address when running configureDR on the target system, answer Y. (You will enter
the source IP address in Steps 23g and 25g.)

Enter the well-known IP address of the target HA system.
i. The following prompt appears:

j. When prompted to confirm the values you have entered, ensure that the listed values are correct and then answer Y.
k. The following prompt appears:

If the file exists:
Answer Y.
14 Source On the source active system, change to user oracle, and create a directory that has enough space to hold a backup of the Insight database.
active
Make a note of this directory pathname. You will need to use this same pathname in Steps 15, 16, 17, and 26.
15 Source As user oracle on the source standby system, create a directory that has the same pathname and size as the directory you created in Step 14.
standby
16 Target As user oracle on the target active system, create a directory that has the same pathname and size as the directory you created in Step 14.
active
17 Target As user oracle on the target standby system, create a directory that has the same pathname and size as the directory you created in Step 14.
standby
18 Source As user oracle on the source active system, enter the following:
active

19 Source The following prompt appears:
active
20 Source As user insight, start Insight on the source active system:

active
$ ./sonusEms start
21 Source As user insight, start Insight on the source standby system:

standby
$ ./sonusEms start
22 Target As user oracle on the target active system, edit the $ORACLE_BASE/.profile file so that it contains the ORACLE_SID value that was displayed in Step 10f.
active
value is SIDR.
Re-login as oracle
As k-shell, enter:
. .profile
As bash, enter:

23 Target Run the configureDR script on the target active system:
active
1. a. As root on the target active system, navigate to the DR directory and run the configureDR script as follows:
# ./configureDR

Answer Y.

Answer Y.

a) source
b) target
Answer b.
Is this the correct ORACLE_SID value the correct setting as specified when you ran ./configureDR on the DR Source system? (default:y) [y|Y,n|N]
f. A message appears that identifies the IP address of the target system. When prompted to confirm that you used this value for the target system when
running configureDR on the source system in Step 10h, answer Y.
g. The following prompt appears:


i. When prompted to confirm the values you have entered, ensure that the listed values are correct and then answer Y.
j. The following prompt appears:

If the file exists:
Answer Y.
24 Target As user oracle on the target standby system, edit the $ORACLE_BASE/.profile file so that it contains the ORACLE_SID value that was displayed in Step 10f.
standby
value is SIDR.
Re-login as oracle
As k-shell, enter:
. .profile
As bash, enter:

25 Target Run the configureDR script on the target standby system:
standby
1. a. As root on the target standby system, navigate to the DR directory and run the configureDR script as follows:
# ./configureDR

Answer Y.

Answer Y.

a) source
b) target
Answer b.
f. A message appears that identifies the IP address of the target system. When prompted to confirm that you used this value for the target system when
running configureDR on the source system in Step 10h, answer Y.
g. The following prompt appears:


i. When prompted to confirm the values you have entered, ensure that the listed values are correct and then answer Y.
j. The following prompt appears:

If the file exists:
Answer Y.
26 Source On the source active system, change to user oracle, and copy the contents from the source active system directory created in Step 14 and put them in the target
active active system directory created in Step 16. The pathname for the directory on the source active and the directory on the target active must be the same.
27 Source As user oracle on the source active system, copy the files from the $ORACLE_BASE/oradata/$ORACLE_SID/arch directory to the same directory on the target active
active system.
28 Source On the source active system, change to user oracle, and enter the following:
active
The following error message appears:
RMAN-00569 ...
..........
Ignore following error messages as long as subsequent steps result in incrementing sequence numbers on the target database
For more information, refer to "Default Account Names and Passwords" in the “Insight Account Names and Passwords.
For more information, refer to “Insight Account Names and Passwords.

29 Source On the source active system, do the following:
active
1. Change to user oracle.
2. Copy the following password file from Source Active System and paste the password file to: the Source Standby system, Target Active system, and Target
Standby system.
The file is $ORACLE_HOME/dbs/orapw$ORACLE_SID
The $ORACLE_SID value at the Source system is SIDB and the $ORACLE_SID value at the target system is SIDR.
For example:
scp $ORACLE_HOME/dbs/orapwSIDB oracle@<SOURCE_STANDBY_IP>:$ORACLE_HOME/dbs/orapwSIDB
scp $ORACLE_HOME/dbs/orapwSIDB oracle@<TARGET_ACTIVE_IP>:$ORACLE_HOME/dbs/orapwSIDR
scp $ORACLE_HOME/dbs/orapwSIDB oracle@<TARGET_STANDBY_IP>:$ORACLE_HOME/dbs/orapwSIDR
30 Target On the target active system, change to user oracle, and enter the following:
active
active
active
The environment is:
ORACLE_HOME=/export/home/oracle/product/10.2.0
ORACLE_SID=SIDB
System altered.
33. Source As user oracle on the source active system, enter the following:
active
SOURCE_SEQUENCE
---------------
172
------------------- ------------------
172 171

34 Source As user oracle on the source active system, perform the following:
active
1. a. Enter the following again:
1. b. Enter the following again:
1. c. Check to see if the SOURCE_SEQUENCE, TARGET_ARCHIVED_SEQ, and TARGET_APPLIED_SEQ values have all incremented from those displayed
in Step 33.
If any of the values have not incremented from those displayed in Step 33, repeat Step 34, substeps a, b, and c every few minutes until all the values have
incremented. It is not unusual for this to take 15 minutes.
35 Source As root on the source active system, enter the following:

active
36 Source As root on the source standby system, enter the following:

standby
37 Target As root on the target active system, enter the following:

active
38 Target As root on the target standby system, enter the following:

standby
39 Target Start Insight on the target active system by logging in as insight and executing the following commands:
active
$ ./sonusEms start

40 Target Start Insight on the target standby system by logging in as insight and executing the following commands:
standby
$ ./sonusEms start
Configuring memory settings...
Starting Fault Management Process Control.
Fault Management Process Control has been started.
Starting Fault Management Sonus Services.
********* HASTATE is standby
********* HASTATE is standby
This system is the Standby HA system. Only some of the Insight processes will be started.
Agent Proxy has been started.
Call Trace Listener has been started.
The RMTEXEC RMI server has been started.
Starting FM Trap Receiver Services
Fault Management Trap Receiver Process started.
Starting Insight!
Insight starting in process 10020
................................................................................................
..................
Failure: Could not start the Sonus Insight server within 1231 seconds.
Please see emsOutput.log and /export/home/ems/weblogic/insight/log/server.log files for more details.
Killed
NOTE: Ignore the following error message:
Failure: Could not start the Sonus Insight server within 1231 seconds.
Setting up DR with an HA source and non-HA Target
This section describes how to setup or upgrade an Insight DR system when the source is an HA system and the
target is a non-HA system.

Prerequisite
Overview of Setting up DR With HA Source and non-HA Target System
Setting Up DR with an HA Source and non-HA Target
Prerequisite
Before setting up DR on a system with an HA source and non-HA target, all the systems need to have Insight
V09.03.00 and you need to perform the following:
Overview of Setting up DR With HA Source and non-HA Target System
The following table gives an overview for setting up DR when the source is an HA system and the target is a non-HA
system. The detailed steps for configuring DR on non-HA systems are in Setting Up DR with an HA Source and
non-HA Target.
HA Source Active System HA Source Standby Target System

System
Prerequisite: Upgrade EMS to V09.03.00 HA system and start Insight. Prerequisite: Upgrade EMS to V09.03.00 HA system and start
Insight.
1. Establish and verify communication between the source and target system.
Stop Insight.
4. Run the delete_data_files.sh script available under

$ORACLE_BASE/orarepl/$ORACLE_SID/scripts/conf
directory to delete the old oracle data files.
Stop Insight.
7. Run configureDR.
Stop Insight.
11. Create a directory to hold a backup of the Insight

database.
12. Create a directory that has the same

pathname and size as the directory you
created in Step 11.
13. Create a directory that has the same pathname and size
as the directory you created in Step 11.
14. Run rman_standby_backup.ksh.
15. Enter the Backup Path.

16. Start Insight.
17. Start Insight.
18. Update $ORACLE_BASE/.profile file with ORACLE_SID

value displayed in Step 4.
20. Copy the contents from the source system directory

created in Step 11 and put them in the target system
directory created in Step 13.
21. Copy database backup files from Step 11 to target system.
22. Run rman_restore_standby.ksh
Note: See RMAN BACKUP for ignoring specific error

messages that appear while running
rman_restore_standby.ksh script.
23. Copy the password file from source active system to

source standby system and target system.
24. Run ./start_standby_database.ksh
25. Run ./enable_primary_database.ksh
26. Run $ ./create_archivelog.ksh
27. Run $ ./sequence_num_status.ksh
28. Run the following:
29. Run ./configureDrMonitoring
32. Run ./sonusEms start
Setting Up DR with an HA Source and non-HA Target

Use the following procedure to configure an Insight DR deployment with an HA source and a non-HA target. Before performing this procedure, both the source and target systems must have
EMS V09.03.00 started at least once on each system.
Enter the command ./sonusEms -d stop (for Insight) to stop Insight. The -d flag indicates that both the core FM and Sonus FM processes are active even after
Insight is stopped. Since the process is active, there will not be any trap loss.
Step System Action
1. Target Establish and verify communication between the source and target system using the method of your choice.
and
source

2. Target Stop Insight on the target system by executing the following command as user insight:
$ ./sonusEms stop
3. Target If this is not the first time you have attempted to configure DR, unschedule DR monitoring on the target system. As root, enter the following:
4. Target On the target system, change to user oracle, and enter the following commands to delete the data files:
5. Source Stop Insight on the source standby system by executing the following commands as user insight:
standby
Allow the database to continue running.
6. Source If this is not the first time you have attempted to configure DR, unschedule DR monitoring on the source standby system. As root, enter the following:
standby
7. Run the configureDR script on the source standby system:
Source a. As root on the source standby system, navigate to the DR directory and run the configureDR script as follows:
standby
# ./configureDR

standby
Answer Y.

standby
Answer N.

standby
a) source
b) target
Answer a.
standby
Answer Y.
standby
When prompted to confirm that you will update the setting on the target system, answer Y. (You will update the setting in Step 18.)

Source g. A message appears that identifies the IP address of the source HA system. Make a note of the value.
standby
When prompted to confirm that you will use this value as the source IP address when running configureDR on the target system, answer Y. (You will enter the source IP
address in Step 20g.)

standby
standby

standby
If the file exists:
Answer Y.
8. Source Stop Insight on the source active system by executing the following command as user insight:
active
9. Source If this is not the first time you have attempted to configure DR, unschedule DR monitoring on the source active system. As root, enter the following:
active
10. Run the configureDR script on the source active system:
Source a. As root on the source active system, navigate to the DR directory and run the configureDR script as follows:
active
# ./configureDR

active
Answer Y.

active
Answer N.

active
a) source
b) target
Answer a.
active
Answer Y.
active
When prompted to confirm that you will update the setting, answer Y. (You will update the setting on the target system in Step 19.)
Source g. A message appears that identifies the IP address of the source HA system. Make a note of the value.
active
When prompted to confirm that you will use this value as the source IP address when running configureDR on the target system, answer Y. (You will enter the source IP
address in Step 19g.)

active
active

active
If the file exists:
Answer Y.
11. Source On the source active system, change to user oracle, and create a directory that has enough space to hold a backup of the Insight database.
active
Make a note of this directory pathname. You will need to use this same pathname in Steps 12, 13, 15, and 20.
12. Source As user oracle on the source standby system, create a directory that has the same pathname and size as the directory you created in Step 11.
standby
13. Target As user oracle on the target system, create a directory that has the same pathname and size as the directory you created in Step 11.

active
15. Source The following prompt appears:

active
16. Source As user insight, start Insight on the source active system:
active
$ ./sonusEms start
17. Source As user insight, start Insight on the source standby system:
standby
$ ./sonusEms start
18. Target As user oracle on the target system, edit the $ORACLE_BASE/.profile file so that it contains the ORACLE_SID value that was displayed in Step 7f.
value is SIDR.
Re-login as oracle
As k-shell, enter:
. .profile
As bash, enter:
19. Run the configureDR script on the target system:
Target a. As root on the target system, navigate to the DR directory and run the configureDR script as follows:
# ./configureDR
Target 1. b. The following prompt appears:
Answer N.
Target c. The following prompt appears:
Answer Y.
Target d. The following prompt appears:
a) source
b) target
Answer b.

Target e. A message appears that identifies the ORACLE_SID setting in the user oracle’s .profile file, and then the following prompt appears:
Target f. A message appears that identifies the IP address of the target system. When prompted to confirm that you used this value for the target system when running
configureDR on the source system in Step 8h, answer Y.
Target g. The following prompt appears:
Target i. When prompted to confirm the values you have entered, ensure that the listed values are correct and then answer Y.
Target j. The following prompt appears:
If the file exists:
Answer Y.
20. Source On the source active system, change to user oracle, and copy the contents from the source system directory created in Step 11 and put them in the target system
active directory created in Step 13. The pathname for the directory on the source and the directory on the target must be the same.
21. Source As user oracle on the source active system, copy the files from the $ORACLE_BASE/oradata/$ORACLE_SID/arch directory to the same directory on the target system.
active

22. Source On the source active system, change to user oracle, and enter the following:
active
Ignore the following error messages as long as subsequent steps result in incrementing the sequence numbers on the target database.
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/export/home/oracle/oradata/SIDB/system01.dbf'
For more information, refer to “Insight Account Names and Passwords.
For more information, refer to the “Insight Account Names and Passwords”, Appendix C.
23. Source On the source active system, do the following:

active
a. Change to user oracle.
b. Copy the following password file from the Source Active system and paste it to the Source Standby system and the Target system.
The file is:$ORACLE_HOME/dbs/orapw$ORACLE_SID
For example:
scp $ORACLE_HOME/dbs/orapwSIDB oracle@<SOURCE_STANDBY_IP>:$ORACLE_HOME/dbs/orapwSIDB
scp $ORACLE_HOME/dbs/orapwSIDB oracle@<TARGET_IP>:$ORACLE_HOME/dbs/orapwSIDR
24. Target On the target system, change to user oracle, and enter the following:
active
active
The environment is:
ORACLE_HOME=/export/home/oracle/product/10.2.0
ORACLE_SID=SIDB
System altered.

active
SOURCE_SEQUENCE
---------------
172
------------------- ------------------
172 171
28. Source As user oracle on the source active system, perform the following:
active
c. Check to see if the SOURCE_SEQUENCE, TARGET_ARCHIVED_SEQ, and TARGET_APPLIED_SEQ values have all incremented from those displayed in Step
27.
If any of the values have not incremented from those displayed in Step 27, repeat Step 28, substeps a, b, and c every few minutes until all the values have incremented.
It is not unusual for this to take 15 minutes.
29. Source As root on the source active system, enter the following:
active
30. Source As root on the source standby system, enter the following:
standby
31. Target As root on the target system, enter the following:
32. Target Start Insight on the target system by logging in as insight and executing the following commands:
$ ./sonusEms start
Upgrading Insight EMS DR
The section provides an introduction to the new upgrade framework, various upgrade paths, and upgrade scenarios

before describing the Insight Software upgrade procedures.
Topics include:
Insight Upgrade Scenarios for EMS DR
Insight Upgrade Considerations for DR
Upgrading Insight Standalone in DR Configuration
Upgrading Insight HA on DR Configuration
Upgrading DR with No HA (Standalone) system
Upgrading DR with an HA source and non-HA Target
Upgrading DR with HA Source and HA Target
Insight Upgrade Scenarios for EMS DR

The following table lists the different Insight software upgrade scenarios:
Scenario Description
Single Insight Server You can upgrade a Standalone Insight software by using the Insight installation script and
Upgrade from Sonus the Sonus Operating System patch from the Sonus Salesforce Customer Portal.
Salesforce Customer
Portal
High Availability System You can upgrade a High Availability Insight software using the Sonus Salesforce Customer
Upgrade using SalesForce Portal.
Customer Portal The Insight High Availability (HA) feature provides for the automatic switchover from an
active Insight system to a standby system in the event the active system fails, thereby
minimizing any downtime in your management capabilities.
Insight Upgrade Considerations for DR

The following are the Insight SA upgrade considerations.
be upgraded:

2.
When upgrading a system that is running HPC, avoid loss of HPC service by installing and
activating the HPC license (NW-HPC) after you upgrade Insight and before you upgrade PSX. See
the Insight EMS User Guide for details.

For upgrading/downgrading PSX Manager independantlyof Insight, refer to the

Guide (PSX Installation and Upgrade Guide).

Insight CLI, SMS API, SGX API, Lawful Intercept Provisioning API, and Traffic Manager.
This section addresses installation and/or upgrade of Insight only. For instructions on installing/upgrading
other network elements, consult the appropriate element guides.
Upgrading Insight Standalone in DR Configuration

Prerequisites for EMS DR Upgrade
Upgrading Insight Standalone DR using Sonus Salesforce
Prerequisites for EMS DR Upgrade
This section provides the prerequisites before planning an Insight upgrade.
Prerequisite for Rollback Using Disk Mirroring
Downloading EMS Bootstrap file for EMS DR Upgrade
Verify/perform the following items prior to upgrading the Insight system to V09.03.00:
You have read "Insight Upgrade Considerations".
You have super user (root) access on the Solaris system.
You should be aware of the Insight account and default passwords. For more details, see Default Account
Names and Passwords.

You have terminal access to the servers on which you are upgrading Insight.
Your system meets the minimum hardware requirements.
The following files need to be downloaded before you start the upgrade:
emsBootstrap-V09.03.00R000.tar Mandatory
Prerequisite for Rollback Using Disk Mirroring
1. If you experience any issues in your production network following an upgrade, you can return to the previous
version of Insight using disk mirroring.
a. The following mirrors are available where disks 0, 1 are master disks and 2,3 are slave disks.
Disk 0 -> Disk 2
Disk 1 -> Disk 3
Refer section Enabling Disk Mirroring for enabling disk mirroring.
b. If you intend to use Disk mirroring as a rollback option, then make sure that mirroring is enabled, and
that the mirrors are in sync, using 'metastat -c' command.
Please note that using Disk mirroring as rollback option will require physical access to the
system, in case of upgrade failure, to swap the disks.
c. After verifying that mirrors are in sync, detach the mirrors, so that mirroring no longer takes place.
Refer to Detaching Slave Disks from the Mirror.
Downloading EMS Bootstrap file for EMS DR Upgrade
Here are the steps to download the EMS Bootstrap file: emsBootstrap-V09.03.00R000.tar from Sonus
Salesforce Customer Portal and place the file in the EMS server:
1. Login to a shell on the EMS Server as root user.


2.
# mkdir -p /export/home/install/ems/
3. Download the emsBootstrap-V09.03.00R000.tar file from the Sonus Salesforce Customer Portal to
4. Untar the emsBootstrap-V09.03.00R000.tar file by entering the following command:
# tar xf emsBootstrap-V09.03.00R000.tar
5. Ensure that all the extracted files have owner and root privileges by entering:
# ls -l
If not, change the owner and groups as follows;
# chown -R root:root *
Upgrading Insight Standalone DR using Sonus Salesforce
This section describes the procedure to perform an Insight Standalone upgrade using the bootstrap
emsBootstrap-V09.03.00R000.tar file that you obtain from the Sonus Salesforce Customer Portal.You should
perform the following procedure to upgrade Insight Standalone on a Netra T5220 systems.
Before upgrading using Sonus Salesforce Customer Portal, you need to take a backup of /etc/inet/nt
p.conf and /etc/issue files. You can restore this after completing the upgrade.
Topics include:

Upgrading PSX Manager GUI on Insight Server
Post Upgrade Tasks
Download the following files from Sonus Salesforce Customer Portal to perform the Insight Upgrade.
Here are the steps to download the Solaris Operating System file Sonus_OS_delta_9.3_Upgrade.tar.gz

For upgrading the Insight to V09.03.00, the Solaris Operating System patch version must be
Generic_150400-20.
# uname -v
Read the output, if the following line appears, the Solaris OS patch has been already installed, and you can
skip the remaining steps.
Generic_150400-20
2. Download the Sonus_OS_delta_9.3_Upgrade.tar.gz file from the Sonus Salesforce Customer Portal to
the /export/home on the target server.
3. Enter to the location /export/home.

Perform the following steps to download the Solaris Firmware files.
# unzip 147309-09.zip

/export/home/packages/147309-09 directory. The 147309-09.zip file is also available from the
Sonus Salesforce Customer Portal at WL9.3.
The Solaris_Utilities_<current_release>.tar is needed while upgrading SNMP software.

If the packages are not at least version 1.6.2, then proceed the remaining steps, otherwise no need upgrade
the SNMP software and skip the remaining steps.
3. Download the Solaris_Utilities_<current_release_name>.tar from the Sonus Salesforce

Customer Portal to /export/home/tmp.

Perform the following steps to verify the Oracle Database version and security patch. If the Database version or
security patch installed is not the latest, download the Oracle Database file
EMS_SonusDBPackage_solaris-V09.03.00R000.tar from Sonus Salesforce Customer Portal to the EMS
server:
For upgrading the Insight to V09.03.00, the Oracle Database version should be 11.2.0.3.0 with the latest
security patch 19271438. Even if the existing database version is 11.2.0.3.0, verify and ensure that you
upgrade to the latest security patch 19271438.

su - oracle
sqlplus -version
If the following line appears, the Oracle Database 11.2.0.3.0 is installed. Even if DB version is
11.2.0.3.0, verify if the latest security patch has been installed.
su - oracle
b. Enter the following command to verify the latest Security Patch Update (SPU) version is applied on the
system:
$ORACLE_HOME/OPatch/opatch lsinv | grep 19271438
If the following line appears, the required Oracle Security Patch has been already installed, and you
can skip the remaining steps.

Patch 19271438 : applied on Wed Oct 01 19:58:21 IST 2014
If the command output does not match the latest Security Patch Update (SPU) version 19271438 then
you need to upgrade the Oracle Database.

a. Download the EMS_SonusDBPackage_solaris-V09.03.00R000.tar file from the Sonus
Salesforce Customer Portal to/export/home/oracle
The EMS.V09.03.00R000.tar.Z file is needed while executing mainInstall.pl
1. Download the EMS.V09.03.00R000.tar.Z from the Sonus Salesforce Customer Portal to

2. Enter the following commands to extract the file:
# tar xvf EMS.V09.03.00R000.tar
Before upgrading Insight, you need to take a backup of /etc/inet/ntp.conf and /etc/issue files.
You can restore this after completing the upgrade.
Perform the following procedure to upgrade Insight using Sonus Salesforce:
1. Running the preInstall.pl.

2. Upgrading the Third Party Software
3. Running the mainInstall.pl.
4. Running the postInstall.pl.
/export/home/ems
/var
/tmp

The following procedure lists how to run the preInstall script:
1. To produce a log of the upgrade, use the /usr/bin/script command to create a record of the terminal
session. This command creates a sub-shell where you run the installation. When it completes, type exit to
terminate the script command. As super user, enter the following command:
2. Run the following preinstall script:
perl preInstall.pl
The preInstall script collects the current configuration details of the machine. The following message
appears:
************************************************************
EMS preInstall.pl for target release version V09.03.00R000
** Run this script BEFORE upgrading current EMS system
** (Press ENTER to select default values shown in braces)
*******************************************************
Starting preInstall.pl execution on : Tuesday, August 2, 2011 10:05:06 AM EDT
1: Upgrade through FTP

2: Upgrade through Jumpstart (HDD/DVD/USB)
Your choice:
Select 1 to upgrade Insight using Sonus Salesforce Customer Portal.

This machine will be used as HA or standalone

(1: HA, 2: Standalone)? (default:1):
Select 2 for Standalone.

5. The following message appears.
If the upgrade path from the installed to the current EMS version is not supported:

5.
Upgrade from current version of EMS "XXXXXXX" to EMS release version "XXXXXX"
is not supported.
Please contact Sonus Customer Support for additional information on supported
Insight Upgrade Paths.
Do you want to proceed with the upgrade procedure (y/n/Y/N)? (default:N):
If the upgrade path is supported but not explicitly tested by Sonus.
Upgrade from current version of EMS "XXXXXXXX" to EMS release version

"XXXXXXX" is supported but not explicitly tested by Sonus. You may go ahead
with the upgrade procedure.
Do you want to proceed with the upgrade procedure (y/n/Y/N)? (default:Y):
Enter N, if you want to stop the upgrade procedure. Or Enter Y, if you want to continue the upgrade
procedure.
6. If you have pressed Y, the following message appears:
Starting checkInstallation.pl execution on : Friday, October 14, 2011 6:22:49
AM EDT
Checking server boot mode...
Verified server boot mode.
Checking "SONSems" package installation...
Package "SONSems" is installed.
Checking user account "oracle"
.
.
.
.......................................................
The following anomalous settings/conditions were detected.
These do not necessarily mean that there is a problem but they might warrant
further investigation:
...................................................
.................................................
......................................................................................Complete
checkInstallation.pl execution on : Tuesday, July 12, 2011 9:38:20 AM
checkInstallation.pl has identified some potential issues.
Press ENTER to continue if you have already investigated these issues.
Press Ctrl + c, if you want to exit from the script. Or Press Enter to continue.
Do you want to take backup of EMS configuration and databases (y/n/Y/N)?

(default:Y)

Enter Y, if you want to take a backup of the EMS configuration and database. Or Enter N, if you do not want
to take a backup of the EMS configuration and database.
Skipping backup of EMS configuration and databases.
Sonus recommends you to take a backup of the system if you need to rollback to the current
version.
8. If you have selected Y in the above prompt, the following prompt appears:
(please note that this may take some time) (y/n/Y/N)? (default:Y):
Enter Y, if you want to import the Activity Logs, PM Stats and TrunkGroup Tables.
Or
Enter N, if you do not want to import the Activity Logs, PM Stats and TrunkGroup Tables.
Do you want to take the backup of Performance CSV files (y/n/Y/N)? (default:N)
Enter Y, if you want to take a backup of the Performance CSV files.

Performance csv files location ?

(default:/export/home/ems/weblogic/sonusEms/data/pm_archive):
If you want to take a backup of the Performance CSV files from a different location, enter the location details.
Or
Enter N, if you do not want to take a backup of the Performance CSV files.
Skipping backup of Performance CSV files.

Running backupData.pl...
.
.........................................
Moving the files to /export/home/backup.
Backup of Performance CSV files complete.
backupData.pl is complete.
Execution of backupData.pl is completed.
Do you want to push backup files to remote host (y/n/Y/N)? (default:Y):
Enter Y, if you want to push the backup files to the remote host.
You will be prompted to enter the following details:
Remote sftp host name or IP
Username for sftp
Login Password
Directory on remote host
Or
Enter N, if you do not want to push the backup files to the remote location.
preInstall is complete. Download the required tar file from Sonus SalesForce
Customer Portal and untar under current directory and run mainInstall.pl to
continue.
Completed preInstall.pl execution on : Tuesday, October 18, 2011 2:53:30 AM
EDT.
If the script indicates that you should upgrade the Operating System and Oracle, upgrade the same using "
Upgrading the Third Party Software".
following:
Upgrade the Third Party software after preInstall.pl execution is complete.


Step 4 Upgrading the Database Software
Step 1: Upgrading Solaris Operating System
If you are upgrading to Insight V09.03.00, the Solaris Operating System patch version should be
Generic_150400-20. Installing the Solaris Patch may approximately take 90 minutes. Before upgrading the
Solaris Patch, you need to determine the Solaris Patch Level.

# uname -v

Generic_150400-20
You can copy the solaris OS patch from the Sonus SalesForce Customer Portal and then perform an upgrade.Copy

Downloading Upgrade Files.


Done
$ exit

$ sqlplus /nolog
SQL> exit
$ exit
/bin/ksh.
# reboot -- -s
3. Enter the root user password when the following prompt appears
5. Perform the following steps to create the OS directory and extract the
commands:

# cd /export/home
space.
# ./upgrade.sh

If you encounter Return Codes 0, 1, 2, 4, or 8 during the patch installation process, you may ignore then.
# reboot -- -r
15+0 records in
15+0 records out
# uname -v

Generic_150400-20

Step 2: Upgrading SNMP Management Agent
1. Determining the SNMP Management Agent Version

2. Upgrading the SNMP Management Agent

details, see Downloading Upgrade Files.
Determining the SNMP Management Agent version:

Upgrading the SNMP Management Agent
1. Login as root.

4.
# ./install.sh
7. Confirm that the SNMP agent is running by entering:
# ps -ef | fgrep snmpd
Step 3: Upgrading ILOM Firmware
If you are upgrading Insight using the Sonus Salesforce Customer Portal, you need to upgrade the ILOM firmware.

2. If system firmware version is not at 7.4.7, then perform Upgrading System Firmware.

sc> resetsc
# unzip 147309-09.zip
This places the sysfwdownload and the Sun_System_Firmware-7_4_7-Netra_T5220.pkg files

in the /export/home/packages/147309-09 directory.
The 147309-09.zip file is also available from the Sonus Salesforce Customer Portal at WL9.3.
.......... (6%).......... (13%).......... (19%).......... (26%)..........

(33%).......... (39%).......... (46%).......... (52%)..........
(59%).......... (66%).......... (72%).......... (79%)..........
(86%).......... (92%).......... (99%).. (100%)


4.
# shutdown -i0

minute
seconds
THE SYSTEM
characters.
{0} ok #
.
a. login:
b. {0} ok
–>
c. {0} ok
sc>
6. After performing step 5, If you are landed in option a.login:(login) prompt:

Password:
Daemons ready
Version 3.0.12.4.y r77080
-> cd /SP/users/
-> ls

-> cd /SP/users/
-> ls

ALOM.
Creating user...


sc> poweroff
sc> showkeyswitch
following command:

NOTE: A flashupdate takes about 6 minutes to load a new file. Some commands
are disabled until the file load is complete. The SC will be reset to complete
the upgrade.

Password:
Daemons ready
Version 3.0.0.0

15.
sc> poweron
sc> console
Done
.................................
|-----------------------------------------------------------------|
console login: root
password:

If you receive a warning message "showmount:RPC: Rpcbind failure - RPC: Unable to receive",
while performing upgrade, you can ignore the warning message.
1. After you unzip the file 147309-09.zip, download the

Sun_System_Firmware-7_4_7-Netra_T5220.pkg file to your local system.
3. In your web browser, type the SP IP address in the location bar. The web interface login page appears.
4. Enter the User Name (default name is root) and the Password (default is changeme), and click the Log In.
8. Click the Save.
12.

14. Click browse and navigate to the directory on your local system containing the firmware file and select
15. Click the Upload button. The file is uploaded. This should take about a minute.
b. Click Start Upgrade.
changeme), and click the Log In.
20. Verify that the Sun System Firmware version displayed is 7.4.7.
23. In the Remote Power Control sub-tab, select Power On from the pull-down list and click Save.
Step 4: Upgrading the Database Software
ID/trace
Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700

For details, see Downloading Upgrade Files.
$ ./sonusEms stop
If the preInstall.pl displays an earlier oracle version earlier than 11.2.0.3.0 or if you have not
applied the latest Security Patch Update then follow the below procedure to upgrade the database to 11.2.
0.3 and apply the latest Security Patch Update (SPU).
Perform the following procedure to upgrade the oracle database:
1. Log on as root. (Command: su - root).

2. Navigate to the following location where Insight 9.3 package is copied.

2.
The UpgradeOracle.sh script upgrades the Oracle and starts the Oracle. This script takes
approximately one hour to complete.

free space:
The following procedure lists how to run the mainInstall.pl script:

1. Before running the mainInstall.pl script ensure that the directory /export/home/install/ems/
contains the required files that were downloaded from the Sonus Salesforce Customer Portal and extracted
here. Ensure that the oracle database instance is also running on server.
2. In order to produce a log of the upgrade, use the /usr/bin/script command to create a record of the
terminal session. This command creates a sub-shell where you run the installation.
When it completes, type exit to terminate the script command.
As super user, enter the following command:
3. Start the mainInstall.pl by entering the following command:

3.
perl mainInstall.pl
*******************************************************
** EMS mainInstall.pl for target release version V09.03.00R000
**
** Run this script AFTER executing preInstall.pl and following instructions
from preInstall.pl
********************************************************************************Starting
mainInstall.pl execution on : Friday, April 04, 2014 5:15:15 AM EDT.
Using "<host_name>.emsConfig.tar" file in "/export/home/backup" directory.

Do you want to download "<host_name>.emsConfig.tar" file from remote host
details:
- Username for sftp
- Login Password
Or
You have to download the <host_name>.emsConfig.tar file manually and place it at
It is required to use the <host_name>.emsConfig.tar generated from the same system.
Using "<host_name>.backupData.tar" file in "/export/home/backup" directory.

Do you want to download "<hostname>.backupData.tar" file from remote host
details:
- Username for sftp
- Login Password

Or
You have to download the <host_name>.backupData.tar file manually and place it at
If you have not upgraded the Solaris and Oracle to the recommended versions before running the
mainInstall.pl script, the script will indicate the same and terminate. You must upgrade the Solaris
and Oracle to the required version and re-run the script.
For information on installing the Solaris Patch and Oracle Database and any other Third party software, refer
to Upgrading the Third Party Software.
The following message appears, if Solaris OS and Oracle are not upgraded:
Please re-run mainInstall.pl after following above instructions.

Exiting...
The script will continue importing data and then restart EMS. The procedure may take around 60 minutes for
an 80 MB DB data.
Checking solaris OS patch...

Checking Database version...
Running emsInstall.sh...
The PSX Manager is not included on this media and will not be installed.
The BRX Manager is not included on this media and will not be installed.
Current and New JBOSS version: 5.1.0-GA::5.1.0-GA09.03.00R000
Removal of <JBSSsrvr> was successful.

Installation of <JBSSsrvr> was successful.
Setting up user 'insight' OS privilege ...
insight
Check for incompatible packages for Insight agent ...
Local Number Portability Application(Tools-> LNPAdaptor) is not being

deployed.
If you need to deploy it, please run the following script as 'root' user:
8.

********************
Uninstalling SONSems
********************
The uninstall may take several minutes to complete if there are many PM
archive files.
Shutting down Sonus Insight and related components!
9. The mainInstall.pl script runs to completion with the following message:
mainInstall is complete. Run postInstall.pl to continue.

Completed mainInstall.pl execution on : Fri Mar 1 20:43:41 IST 2013
10. After the mainInstall.pl execution is complete, it indicates the same and instructs you to run the
postInstall.pl.
Running the postInstall.pl
Running the postInstall.pl may approximately take one minute.
Perform the following procedure to run the postInstall.pl script:
1. Run the postInstall.pl script by entering the following command:
perl postInstall.pl
*******************************************************
** EMS postInstall.pl for target release version V09.03.00R000
**** Run this script AFTER executing mainInstall.pl

****************************************************************
Starting postInstall.pl execution on : Friday, July 15, 2011 3:19:11 AM EDT
2. After postInstall.pl execution is complete, the following message appears:
postInstall is complete. Current EMS version is V09.03.00R000
Completed postInstall.pl execution on : Friday, July 15, 2011 3:19

3. Type exit to exit from the script.
4. All the script logs are available in logs/ directory and in the file that you have mentioned while starting the
script command.
1. a. Login to Insight.
i. SSH Port
ii. Login (CLI)
iii. Password (CLI)
e. Click on Update and then click on Discover node.
2. If upgrade fails to complete successfully, perform the following to roll back to old EMS version.
b. Mount Mirrored disk.

The ‘/’ slice on the mirrored disk need to be mounted locally in order to edit two files on the /etc path
(which lives of ‘/’slice).
' '`s0"


Example:

c. Edit /mnt/etc/vfstab
# cd /mnt/etc
# echo | format


example below.

mount
options
#
no -
no -
yes -
yes -
yes -

slot 0.
d. Edit /mnt/etc/system as root user and delete the following lines if present:


e. Unmount /mnt as root user:
# cd
# umount /mnt
f. Physically swap disks and reboot system:

i. Shutdown the system by running following command as root user:

f.
i.
# init 5
ii. Perform disk swap.

Disks initially at slots 0 and 1 should be inserted back to slots 2 and 3. Otherwise, it
will result in system booting in maintenance mode.
iii. Power up and reboot the system.

If performing the rollback on an HA EMS configuration, then allow the Active server to
completely recover before powering on the Standby server.
g. Verify mirror status.
# metastat -c
d201 m 60GB d21
d21 s 60GB c1t1d0s1
d200 m 219GB d20
d106 m 2.0GB d16
d105 m 50GB d15
d15 s 50GB c1t0d0s5
d104 m 202GB d14
d103 m 4.0GB d13
d100 m 5.0GB d10
d101 m 15GB d11
d11 s 15GB c1t0d0s1
d41 s 60GB c1t3d0s1
d35 s 50GB c1t2d0s5
d31 s 15GB c1t2d0s1
h. Dump device need to be set to the original device (e.g. /dev/dsk/c1t0d0s1 for the example above)

h.
i. If you need to restart disk mirroring, clear the metadb and enable the disk mirroring using dmctl. The
# metaclear d41
# metaclear d40
# metaclear d36
# metaclear d35
# metaclear d34
# metaclear d33
# metaclear d30
# metaclear d31
# metaclear -r d201
# metaclear -r d200
# metaclear -r d106
# metaclear -r d105
# metaclear -r d104
# metaclear -r d103
# metaclear -r d100
# metaclear -r d101
j. Execute the following command to list all the existing metadb state database replicas.
# metadb

k. Clear all the metadb state database replicas using the following command:
# metadb -df <replica1> <replica2> <replica3> <replica4>.
l.

l. In the above example, replicas are cleared using command:
m. Execute following command to verify that all mirroring configurations are cleared. These commands
# metastat -c
# metadb -i
n. Re-enable disk mirroring by following Enabling Disk Mirroring.
There will be downtime during the procedure since server will be rebooted as part of re-enabling disk
mirroring.
Upgrading PSX Manager GUI on Insight Server

package.

8.
# ./GuiClient.sh



Post Upgrade Tasks
For more information on Post-Install/Upgrade tasks, see Post-Installation/Upgrade Tasks.
Upgrading Insight HA on DR Configuration

This section describes how to upgrade an Insight High Availability (HA) system using Sonus SalesForce Customer
portal.
To configure an HA on Netra T5220, see Insight HA Configuration for EMS DR.
This section contains the following sub-sections:
Prerequisites for Insight HA DR Upgrade

Downloading Insight Upgrade Files for DR Configuration
Obtaining the TAR Files for DR Upgrade
DR HA Upgrade Steps-An Overview
Upgrade procedure for Insight HA in DR Configuration
Upgrading PSX Manager GUI on Insight HA Server for DR Configuration
Rollback to Previous Version using Disk Mirroring - DR Configuration
Post-Upgrade Tasks - DR Configuration
Prerequisites for Insight HA DR Upgrade
Verify or perform the following tasks prior to upgrading Insight HA.

Tasks Description
Required Ensure that there is enough space in /export/home.

Space
For example, 20GB of free space.
Super root Ensure that you have the following:

access and
Terminal Super root access on the Solaris system
Access Terminal access to the HA servers
HA State Verify that the HA is configured correctly and EMS is up and running.
The HA state should be either ACTIVE/ACTIVE Or STANDBY/STANDBY.

File Transfer The Solaris OS and Oracle DB related files are transferred to each of the host’s reachable IP only through
scp command.
Tar file Extract the tar files.

Extraction
Do not use verbose option of tar command (use tar xf instead of tar xvf).
Delete or remove any .tar or tar.gz files that are available after the extraction. This is
performed to increase the space in the folder.
emsbootstrap Download the Insight EMS installer file from the Sonus SalesForce Customer Portal and place it at
Download /export/home
For example:
EMS.V09.03.00R000.tar.Z for FTP based upgrade

emsBootstrap-V09.03.00R000.tar for Jumpstart based upgrade.
Uncompress the installer file:

The EMS Installer script automatically untars the file.
Insight Ensure that the passwords for “insight” system user is same on both the systems.
Passwords

Recording Ensure that you record the screen output using the script command. This enables you to troubleshoot any
the Screen issues while performing an upgrade.
output
Ensure that you run the script command before extracting the tar file.
To start session recording, enter the following:

To stop session recording, type the following:

# Script done, file is /export/home/ems2.script.log
Hardware Ensure that your system meets the minimum hardware requirements.
Requirements
For more details, see Hardware Requirements and Other Restrictions for HA DR.
HA Upgrade All HA upgrade procedures should be performed in sequence.

Procedure
All commands should be run from /export/home/install/ems and run as root
Change to the installation staging directory as shown below:
# cd /export/home/install/ems/
Session recorder (script command) should be already running.
CSV files The upgrade script will restore all csv from
/export/home/ems/weblogic/sonusEms/data/pm_archive on the configured Active
system, if the user enters 'y' to PM retention in Step 1 - Verifying system configuration - Standby
system of the HA Upgrade.
Any csv in the /export/home/ems/weblogic/sonusEms/data/pm_archive on the
configured Standby will not be retained. You have to manually tar up and then back the tar file
to a different location, before the upgrade and restore it after upgrade if required.
Any csv written to a non-standard directory other than (
/export/home/ems/weblogic/sonusEms/data/pm_archive) will not be retained, even if
it is on the Active or Standby system.
It is recommended to export the PM collection on the RAID directory (
/export/home/ems/weblogic/sonusEms/dataRaid/pm_archive), so that the csv files
are always preserved during upgrade.
Insight For information on the latest supported upgrade paths, refer to the 550-05917_Insight_9.3_Release_Notes for
Upgrade Solaris.
Paths
List of Files to be Downloaded before Upgrade

emsBootstrap-V09.03.00R000.tar NA
Prerequisites for Rollback using Disk Mirroring
of Insight using disk mirroring.
1. The following mirrors are available where disks 0, 1 are master disks and 2,3 are slave disks.
a. Disk 0 -> Disk 2
b. Disk 1 -> Disk 3
See Enabling Disk Mirroring-DR Solaris for enabling disk mirroring.
2. If you intend to use Disk mirroring as a rollback option, then make sure that mirroring is enabled, and that the
mirrors are in sync, using 'metastat -c' command.
Please note that using Disk mirroring as rollback option will require physical access to the system, in
case of upgrade failure, to swap the disks
3. After verifying that mirrors are in sync, detach the mirrors, so that mirroring no longer takes place. See
Detaching Slave Disk from the Mirror-DR Solaris.
4. Backup the files on RAID
As user root, login to the Active server and make a backup copy of the RAID directories. This will be used in
case of rollback:
drwx------ 2 root root 8192 May 24 11:20 lost+found
drwxrwxr-x 3 oracle dba 512 May 24 14:27 orasql
drwxrwxr-x 3 oracle dba 512 May 24 14:27 oradata
drwxr-xr-x 3 insight insight 512 May 24 14:37 Omnibus
drwxr-xr-x 4 root root 512 May 24 15:44 sonusEms
# cd /export/raid
# cp -pR orasql orasql_old
# cp -pR oradata oradata_old
# cp -pR Omnibus Omnibus_old
# cp -pR sonusEms sonusEms_old
Downloading Insight Upgrade Files for DR Configuration
Download the following files from the Sonus Salesforce Customer Portal to perform the Insight Upgrade.
Table 109: Files to be Downloaded from Salesforce Customer Portal

Application Software: 1. Login to a shell on the EMS Server as root user.

EMS.V09.03.00R000.tar.Z 2. Download the EMS.V09.03.00R000.tar.Z file from the Sonus Salesforce Customer Portal to /export/home
Solaris Operating System:

Sonus_OS_delta_9.3_Upgrade.tar.gz
For upgrading the Insight to V09.03.00, the Solaris Operating System patch version should be 15
0400-20.

# uname -v
2. Read the output, if the following line appears, the Solaris OS patch has been already installed, and you can skip the
remaining steps.
Generic_150400-20
3. Download the Sonus_OS_delta_9.3_Upgrade.tar.gz file from the Sonus Salesforce Customer Portal to the
/export/home on the target server.
4. Specify the location as /export/home.

Oracle Database: Perform the following steps to verify the Oracle Database version and security patch. If the Database version or security
EMS_SonusDBPackage_solaris-V09.03.00R000.tar patch installed is not the latest, download the Oracle Database file EMS_SonusDBPackage_solaris-V09.03.00R000
.tar from Sonus Salesforce Customer Portal to the EMS server:
For upgrading the Insight to V09.03.00, the Oracle Database version should be 11.2.0.3.0 with
the latest security patch 19271438. Even if the existing database version is 11.2.0.3.0, verify and
ensure that you upgrade to the latest security patch 19271438.

su - oracle
sqlplus -version
If the following line appears, the Oracle Database 11.2.0.3.0 is installed. Even if DB version is 11.2.0.3.0, verify
if the latest security patch has been installed.
su - oracle
b. Enter the following command to verify the latest Security Patch Update (SPU) version is applied on the system:
$ORACLE_HOME/OPatch/opatch lsinv | grep

19271438
If the following line appears, the required Oracle Security Patch has been already installed, and you can skip
the remaining steps.
Patch 19271438 : applied on Wed Oct 01

19:58:21 IST 2014
If the command output does not match the latest Security Patch Update (SPU) version 19271438 then you
need to upgrade the Oracle Database.

a. Download the EMS_SonusDBPackage_solaris-V09.03.00R000.tar file from the Sonus Salesforce Customer
Portal to/export/home/oracle

Solaris Utilities File: Solaris_Utilities_<current_ The Solaris_Utilities_<current_release>.tar is needed while upgrading SNMP software.
release_name>.tar

If the packages are not at least version 1.6.2, then proceed the remaining steps, otherwise no need upgrade the
SNMP software and skip the remaining steps.
3. Download the Solaris_Utilities_<current_release_name>.tar from the Sonus Salesforce Customer Portal to /export/ho
me/tmp.
Obtaining the TAR Files for DR Upgrade
This section describes the procedure for upgrading, using the tar files that is obtained from the Sonus Salesforce
Customer portal.
The following is the tar file used while upgrading Insight.
Installer.tar — The installer file EMS.V09.03.00R000.tar.Z is used while upgrading Insight using the Sonus
Salesforce Customer Portal. The installer file includes the bootstrap file emsBootstrap-V09.03.00R000.tar
Hence, you need not download the bootstrap file separately. The size of the Installer file is over 3GB.
If you are upgrading Insight using the Sonus Salesforce Customer Portal, see "Obtaining Installer file to
upgrade Insight using SalesForce Customer Portal"
Obtaining Installer file to upgrade Insight using SalesForce Customer Portal
Perform the following procedure both in Active and Standby servers.
The following section describes the procedure for obtaining the Installer file to upgrade Insight using the Sonus
Salesforce Customer Portal.
1. Login to a shell on the EMS server as a root user.

2. To start session recording, enter the following:

3.
# cd /tmp/
# tar xvf /export/home/EMS.V09.03.00R000.tar commonFunctions.sh
# bash commonFunctions.sh extractTar /export/home
Setting up EMS install staging area before upgrade...

Looking for Insight EMS installer tar under /export/home...
Insight EMS INSTALLER tar file...: /export/home/EMS.V09.03.00R000.tar.Z
Installation staging directory...: /export/home/install/ems
Current EMS version...............: V09.03.00R000
Do you want to proceed with extracting the tar file to staging directory?
(default: n) [y|n]: y
4. Enter y, if you want to extract the tar file to the staging directory.
Removing /export/home/install/ems. Please wait...

Moving /export/home/EMS.V09.03.00R000.tar.Z to /export/home/install/ems.
Extracting installer tar file into /export/home/install/ems. Please wait...
Checking if extraction was successful...
Found bootstrap tar /export/home/install/ems/emsBootstrap-V09.03.00R000.tar
Extracting bootstrap tar emsBootstrap-V09.03.00R000.tar into
/export/home/install/ems
Creating backup directory /export/home/backup
Changing file ownership of /export/home/install/ems to root
Making script permissions executable
Making HA script permissions executable
Removing the installer tar file...
Successfully completed extraction of Insight EMS INSTALLER tar file.
DR HA Upgrade Steps-An Overview
The List of upgrade steps and approximate time duration table lists an overview of the sequential steps and the
approximate time duration required for performing each step.

Table 110: List of upgrade steps and approximate time duration
Sequence System which owns Well known IP Active Standby Time Duration
No (A-Active, S-Standby) (approximate)
3. A makeStandalone 15 minutes
4. A backupDatabase upgradeSystem 1 hour - Database

Backup
6 hours - Upgrade
using Sonus
SalesForce
5. A pushFiles 15 minutes
6. A restoreDatabase 2 hours
7. * makeStandalone 15 minutes
8. * makeStandby 30 minutes
9. S upgradeSystem 6 hours - Upgrade

using Sonus
SalesForce
10. S pushFiles
11. S restoreDatabase 2 hours
12. S makeActive 30 minutes
13. * failOver 15 minutes
'*' denotes the steps during which the HA EMS server is down.
'A' denotes the steps where the well-known IP is owned by the Active EMS.
'S' denotes the steps where the well-known IP is owned by the Standby EMS.
After performing all the steps listed, you need to perform the Setting up peer root connection on both
the Active and Standby systems.
Upgrade procedure for Insight HA in DR Configuration
This section describes how to upgrade Insight HA using the following steps.
Ensure that all commands are run from /export/home/install/ems and run as root.
Topics include:


To verity the system configuration, you need to run./emsUpgrade.sh checkSystem on the Standby system.
This script checks, collects and displays the system configuration settings. Additionally it also prompts you to enter
the details such as the type of upgrade or status of the PM data and so on.
However, the configuration changes are not performed during this step.
2. Run the following command on the Standby system:
This step will check, collect and display some system configuration settings.
No configuration changes will be made to the system during this step.
----------------------------------------------------------------------------------------------
EMS can be upgraded via either of the options
below:
1. FTP -In-place upgrade from SalesForce Portal (custom non-EMS
settings are retained)
2. JUMPSTART -USB/HDD upgrade (custom non-EMS settings may be lost)
Which option do you plan to use? [1|2]:1
4. Enter 1, to upgrade using the Sonus Salesforce Customer Portal.
EMS V09.03.00 Software Release does not support Jumpstart installation and upgrade using USB.
If you want to use EMS V09.03.00 Software for Solaris platform, you must upgrade using Sonus
Salesforce to EMS Software Release V09.03.00. EMS Software Release V09.03.00 only supports
FTP Inplace upgrade from Salesforce portal for Solaris platform.

----------------------------------------------------------------------------------------------
Insight EMS upgrade, it is recommended that Performance Management (PM)
statistics
data NOT be retained and carried forward.
Retaining PM statistics data could significantly increase the upgrade
downtime.
Do you want to retain PM stats related data? (default: n) [y|n]: .......y
5. Enter y, if you want to retain the PM stats related data.
You chose to RETAIN Performance Management statistics data (longer

downtime).
..............................................................................................
if Database Software version will need to be upgraded...
You will need to upgrade the Database Software version from current 11.2.0 to
new version 11.2.0.3 in a later step.
Please
note that as part of that Database Software version upgrade, SKIP the
database export (before upgrade) and import (after upgrade) steps.
Database export and import will be automatically handled by this script and
should NOT be done manually.
Press Enter key to continue...
6. Press Enter key to continue.
user's password.
.......................................................
......................................................
................................................
Do you want to proceed with getting configuration info? (default: n) [y|n]:
y

/export/home/ems
/var
/tmp
7. Enter y, if you want to proceed to obtain the configuration information.


...........................................................
Starting run of preInstall (Phase: GET_CONFIG) script. Please wait...
*** START: Running preInstall.pl script[GET_CONFIG], at Monday, April1, 2013
4:41:52 PM EDT **
----------------------------------------------------------------------------------------------
preInstall.pl (GET_CONFIG phase) execution on : Monday, April1, 2013
4:41:52 PM EDT
Starting checkInstallation.pl execution on : Monday, April 1, 2013
4:41:53 PM EDT
Creating emsInstall config file...
Creating installation report file...
Please inspect these installation related files before proceeding with

upgrade.
------------------------------------------------------------------
Config settings ........: /export/home/backup/emsInstall.cfg
Installation Report ...: /export/home/backup/preInstallReport.txt
Warnings/errors ........: /export/home/backup/installWarnErrors.txt
------------------------------------------------------------------
Completed preInstall.pl (GET_CONFIG phase) execution on : Wednesday, August

14, 2013 3:58:10 PM IST
----------------------------------------------------------------------------------------------
END: Running preInstall.pl script [GET_CONFIG], at Wednesday, August 14, 2013
3:58:10 PM IST ***
Successfully completed run of preInstall.pl script to collect config
Completed running preInstall (Phase: GET_CONFIG) script, verified backup tar
files.
..............................................................................................
copied install settings file to peer .......
Setting right perms for backup dir
Completed getting system configuration before upgrade.

Caution
To verify the system configuration on the Active system, follow the same procedure as listed in Step 1 Verifying
system configuration - Standby system.
However, in the Active System, you are not prompted for additional information such as the type of upgrade.
The steps for running the checksystem script on Active is similar to Standby.
To convert the HA Standby System into a Standalone, run./emsUpgrade.sh with argument makeStandalone.
This step points to the database on the Standby system from the RAID drive to the local disk. This is performed to
prepare the upgrade of the Standby system.
1. Enter the following command to make the HA Standby system into a Standalone.

.........................................
..........................................

...........................
........................................................
[y|n]: y
3. Enter y, if you want to convert the HA Standby into a Standalone system.

Initiating Insight EMS stop.

................................................
Upgrade using the Sonus Salesforce Customer Portal and upgrade the third party software and continue to the next
step (Step 4b). For details, see "Upgrading the Third Party Software".
You can perform both Upgrading the Standby (Step 4a) and Performing the DB backup on the active system (Step
4b) simultaneously.
following:


If you are upgrading to Insight V09.03.00, the Solaris Operating System patch version should be 150400-07.
Installing the Solaris Patch may approximately take 90 minutes. Before upgrading the Solaris Patch, you need to
determine the Solaris Patch Level.
1. Determining the Solaris Patch Level

2. Upgrading the Solaris OS Patch
# uname -v

Generic_150400-20
You can copy the Solaris OS patch from the Sonus Salesforce Customer Portal and then perform an upgrade.Copy

Downloading Insight Upgrade Files.


Done
$ exit

$ sqlplus /nolog
SQL> exit
$ exit
Caution
/bin/ksh.
# reboot -- -s
3. Enter the root user password when the following prompt appears:

5.
# ./upgrade.sh
If you encounter Return Codes 0, 1, 2, 4, or 8 during the patch installation process, you may ignore
them.
# reboot -- -r

15+0 records in
15+0 records out
# uname -v
Generic_150400-20

details, see Downloading Insight Upgrade Files.


Netra T5220:

1. Login as root.
# cd /export/home/tmp/UTILITIES_<current_release_name>/SNMP_1.6.2
# ./install.sh
Netra T5220:
1.

2. If system firmware version is not at 7.4.7, then perform Upgrading System Firmware
sc> resetsc
# unzip 147309-09.zip

/export/home/packages/147309-09 directory.
The 147309-09.zip file is also available from the Sonus Salesforce Customer Portal at: WL9.3

.......... (6%).......... (13%).......... (19%)..........

(26%).......... (33%).......... (39%).......... (46%)..........
(52%).......... (59%).......... (66%).......... (72%)..........
(79%).......... (86%).......... (92%).......... (99%).. (100%)
# shutdown -i0

The system
crown will be shut down in 1 minute

The system
crown will be shut down in 30 seconds

THE SYSTEM

characters.

5.

{0} ok #.
a. login:
b. {0} ok
->
c. {0} ok
sc>
6. After performing step 5, If you are landed in option a.login: (login) prompt:

Password:
Daemons ready
Version 3.0.12.4.y r77080
-> cd /SP/users/
-> ls

-> cd /SP/users/
-> ls

ALOM.

Creating user...



sc> poweroff
sc> showkeyswitch
following command:

NOTE:
A flashupdate takes about 6 minutes to load a new file. Some commands
are disabled until the file load is complete. The SC will be reset to
complete the upgrade.


Password:
Daemons ready
Version 3.0.0.0
sc> poweron
sc> console
Done

.................................
|-----------------------------------------------------------------|
console login: root
password:


1. After you unzip the file 147309.zip, download the Sun_System_Firmware-7_4_7-Netra_T5220.pkg

file to your local system.
The 147309.zip file is also available from the Sonus Salesforce Customer Portal.

4. The web interface login page appears.
button.
15. Click browse and navigate to the /export/home/packages/147309-09 directory and select
16. Click the Upload button.
The file is uploaded. This should take about a minute.
b. Click the Start Upgrade button.
changeme), and click the Log In button.
21. Verify that the SP Firmware Version displayed is 7.4.7.
24. In the Remote Power Control sub-tab, select Power On from the pull-down list and click the Save button.

For details, see "Downloading Insight Upgrade Files"

Error Codes:
ORA-00942
ORA-942
ORA-00704
ORA-39700
$ ./sonusEms stop
Perform the following procedure to upgrade the current database 11.2.0.1.0 or 10.2.0.4.0 to Oracle 11.2.0.3 or to
apply latest Security patch, after downloading the Oracle 11.2.0.3 package from the Sonus Salesforce Customer
Portal..
You need not perform a manual database backup if you are upgrading using the preInstall.pl script.
Perform the following procedure to upgrade the database software:
1. Log on as root. (Command: su - root)

2. Navigate to the following location where Insight 09.03.00 package is copied.
The UpgradeOracle.sh script upgrades and brings up the Oracle. The script approximately takes
one hour to complete.
You can perform a database backup on Active system using this step. This step backs up the EMS database,
configuration files, and the current state of the Fault Manager. You are recommended not to perform any
configuration changes to EMS from this step till the end of Step 8, because any configuration changes performed
are not retained.
You can perform both Step 4a Upgrading the Standby (Standalone) System and Performing the Database backup
on the Active System (Step 4b) simultaneously.

# ./emsUpgrade.sh backupDatabase
Starting backup of HA Active system 'ems2' database...
.................................
This HA (Active) host......: ems2
Peer HA (Standby) host.....: ems3
.........................................................
..........................................................
Do you want to proceed with backing up the database? (default: n) [y|n]: y
Enter y, if you want to proceed with database backup.

Moving standby tar to /export/home/backup/ems3.backupData.tar

...................................
Completed backup of HA Active system 'ems2' database.
In this step, certain files are moved or pushed from the Active to Standby system. These files are required later by
the Standby system.

Determining if this is the HA active or standby system
user's password.
This step will push certain required tar files to the HA Standby peer system
ems3...
Please make sure that peer system (OS/DB) has been successfully upgraded via
USB/FTP option.
You should run this step after peer system upgrade is complete.
Peer's EMS software will be upgraded automatically in later (restoreDatabase)
step.
4. Enter y, if you want to proceed with moving the files from Active to Standby.
Checking if backup directory is present on the peer ems3...

Verified that backup directory on peer is correctly setup.
Copying only backupData.tar to HA peer system ems3 [10.54.58.105]. Please
wait...
ems3.backupData.tar...
...................................
Successfully copied backupData.tar to HA peer system ems3


Local Insight EMS server http://ems3 will be started at the end of this step
.Following settings are being used for this upgrade:
.............................
4. Enter y, if you want to restore the database and upgrade Insight.


.....................................................
For IPv6 configured systems, reboot (reboot -- -r) the system as root user after completing the
database restore.

3.
.........................................
..........................................

..................................
...................................................
This step will also STOP the following Insight EMS servers:
1. HA Insight EMS running on Well-known IP
2. Standalone Insight EMS running on Peer
[y|n]: y
4. Enter y, if you want to proceed making the Standby into a Standalone system.

................................................
This step configures the system as HA Standby, mount the RAID and then moves the database and certain files to
RAID. At the end of this step, the Insight server is started on the well-known IP.
# ./emsUpgrade.sh makeStandby

3.
user's password.
Converting this Standalone system ems3 to HA STANDBY
Insight EMS server http://ems3 will be shut down if running.
Insight EMS server http://10.54.58.104 will be started up.

.........................................................
Do you want to proceed? (default: n) [y|n]:y

.................................
In this step, you need to upgrade the Third Party Software such as the Operating System, Oracle Database, SNMP
and ILOM.
You can perform the similar steps followed in Step 4a Upgrading the Standby (Standalone) System.
In this step, you need to move or push certain files from the Standby to the Active system.

Determining if this is the HA active or standby system.
This is the HA STANDBY system
.....................................................
.....................................................
user's password.
Setting up connection to HA peer. You may be prompted for remote
'insight' user's password.
Testing peer connection, getting remote host name
No files needed to be transferred as this is an FTP based upgrade.

....................................................
................................
4. Enter y, if you want to proceed with restoring the database and upgrading Insight.

.....................................................
For IPv6 configured systems, reboot (reboot -- -r) the system as root user after completing
the database restore.
This step configures the system as HA Active, mounts the RAID, and then moves the database and relevant files to
the RAID.
# ./emsUpgrade.sh makeActive

user's password.
Converting this Standalone system ems2 to HA ACTIVE
Converting this system to HA ACTIVE...

....................................
................................................
Converting this system ems2 to HA ACTIVE with role override option. Please
wait for this to finish...
..................................................
Verified that HA states are as expected (STANDBY/ACTIVE) after Insight EMS
startup.
During this step, the Standby system currently has the HA resources and EMS running on the well-known IP. This
final step performs a manual failover and brings the HA system to the same state before the upgrade.
# ./emsUpgrade.sh failOver

Checking HA states
...................................................
user's password.
Checking HA states on peer ems2...
Successfully verified that peer ems2 is in correct HA state.
Performing an HA Failover to make this system into HA Standby and peer system
into HA Active.
Starting HA failover. Please wait for this to finish (about 15 mins)...

HA fail over will be requested. Please be patient.
Operation successfully completed.
Re-checking HA states...
Verifying HA states on this system ems3...
Verifying HA states on peer system ems2...
Successfully completed failover.
Upgraded Insight EMS server is now accessible via http://10.54.58.104
a. Login to Insight.
i. SSH Port
ii. Login (CLI)
iii. Password (CLI)
e. Click on Update button and then click on Discover node.
Upgrading PSX Manager GUI on Insight HA Server for DR Configuration
This procedure need to be performed on both the active and standby server.

2.

package.
# ./GuiClient.sh


11. You can perform the steps from 12 to 16 on any one of the servers. The configuration will reflect on both the
active and standby servers.
15.

Rollback to Previous Version using Disk Mirroring - DR Configuration
2. If upgrade to V09.02.00R000 is successful, perform the following procedure:
a. If you have previously detached disk mirrors before upgrade, then Reattach Disk Mirrors to
re-establish the disk mirroring. See Reattaching Slave Disk to the Mirror-DR Solaris.
b. If you have never setup disk mirroring and would like to setup disk mirroring now (check hardware
requirements), then enable disk mirroring. See Enabling Disk Mirroring-DR Solaris.
3. If upgrade to V09.02.00R000 failed to complete successfully, perform the following to roll back to old EMS
version.
b. Restore RAID paths on HA Active server. (This step need not be performed on HA Standby server).
i. Shut down Oracle Database server. See Starting and Stopping the Insight Database-DR Solaris
section in Common Administrative Tasks-DR Solaris.
ii. Copy the previously saved RAID sub-directories back:
# cd /export/raid
# rm -R orasql
# rm -R oradata
# rm -R Omnibus
# rm -R sonusEms
# cp -pR orasql_old orasql

# cp -pR oradata_old oradata
# cp -pR Omnibus_old Omnibus
# cp -pR sonusEms_old sonusEms
# rm -R orasql_old
# rm -R oradata_old
# rm -R Omnibus_old
# rm -R sonusEms_old
c. Mount Mirrored disk.

The ‘/’ slice on the mirrored disk need to be mounted locally in order to edit two files on the /etc
path (which lives of ‘/’slice).

' '`s0"


Example:
d. Edit /mnt/etc/vfstab
# cd /mnt/etc
# echo | format


example below.

mount
options
#
no -
no -
yes -
yes -
yes -

slot 0.
e. Edit /mnt/etc/system as root user and delete the following lines if present:


f. Unmount /mnt. As root user, do
# cd
# umount /mnt
g. Physically swap disks and reboot system:

1.) Shutdown the system by running following command as root user:

g.
# init 5
2.) Perform disk swap.

Disks initially at slots 0 and 1 should be inserted back to slots 2 and 3. Otherwise, it will
result in system booting in maintenance mode.
3.) Power up and reboot the system.

Allow the Active server to completely recover before powering on the Standby server.
h. Verify mirror status.

# metastat -c
d201 m 60GB d21

d21 s 60GB c1t1d0s1
d200 m 219GB d20
d106 m 2.0GB d16
d105 m 50GB d15
d15 s 50GB c1t0d0s5
d104 m 202GB d14
d103 m 4.0GB d13
d100 m 5.0GB d10
d101 m 15GB d11
d11 s 15GB c1t0d0s1
d41 s 60GB c1t3d0s1

d35 s 50GB c1t2d0s5
d31 s 15GB c1t2d0s1
i. Dump device need to be set to the original device (e.g. /dev/dsk/c1t0d0s1 for the example above)

i.
j. If you need to restart disk mirroring, clear the metadb and enable the disk mirroring using dmctl. The
# metaclear d41
# metaclear d40
# metaclear d36
# metaclear d35
# metaclear d34
# metaclear d33
# metaclear d30
# metaclear d31
# metaclear -r d201
# metaclear -r d200
# metaclear -r d106
# metaclear -r d105
# metaclear -r d104
# metaclear -r d103
# metaclear -r d100
# metaclear -r d101
Execute the following command to list all the existing metadb state database replicas.
# metadb

Clear all the metadb state database replicas using the following command:

# metadb -df <replica1> <replica2> <replica3> <replica4>
In the above example, replicas are cleared using command:
k. Execute following command to verify that all mirroring configurations are cleared. These commands
# metastat -c
# metadb -i
l. Re-enable disk mirroring by following Enabling Disk Mirroring-DR Solaris.
There will be downtime during the procedure since server will be rebooted as part of
re-enabling disk mirroring.
Post-Upgrade Tasks - DR Configuration
After you have upgraded Insight HA to V09.02.00 perform the following:
Setting up peer root connection
Password-less connection for root user needs to be established to the peer HA node after the upgrade
completes.This step can be done while HA EMS server is up and running.
You need to perform this step on both the Active and Standby systems.
Perform the following procedure to set the peer root connection:
1. Run the following command on both the nodes:
# ./configureHA -c setupPeerRootSsh

Setting up 'root' user password-less connection to peer system.
Using the existing key, since key already exists
Please enter the root password of the peer 10.6.20.224 node:

...

system.

system.
Upgrading DR with No HA (Standalone) system

This section describes how to upgrade an Insight DR system when neither the source nor the target is an HA
system.
The Insight DR solution is supported for one-disk or two-disk database configurations, but the primary and
the target systems must have the same database configuration when they are both non-HA. (Netra T5220s
always have the two-disk database configuration.)
Topics include:
Overview of DR Upgrade with No HA (Standalone) System

DR Upgrade with No HA System
Overview of DR Upgrade with No HA (Standalone) System
The following table provides the overview steps for upgrading DR with No HA:
Step Source System Target System
1. Convert target to standalone.
2. Convert source to standalone.
3. Upgrade standalone. 4. Upgrade standalone
For upgrading Insight, see "Upgrading Insight For upgrading Insight, see "Upgrading Insight Standalone
Standalone system" in DR Configuration"
5. Configure standalone as target.
6. Configure standalone as source.

Step 3 and step 4 can be performed in parallel.
DR Upgrade with No HA System
Before setting up DR with no HA systems, perform the following to upgrade EMS on the systems that will be part of
the DR setup.
1. If you are upgrading to V09.03.00, you must convert all target and source systems to standalone systems
before upgrading to V09.03.00DR.
For details, see Failover: Converting DR System non-HA Source and Target to Separate non-DR Insight
Servers.
2. Upgrade Insight to V09.03.00 on both the Source and Target systems.

For details, see Upgrading Insight Standalone in DR Configuration.
You must use the same database instance name on both the source and target systems when installing or
upgrading Insight for systems that have never been part of a Data Guard DR setup. (The database instance
names on the target will later be changed as part of the DR configuration.) If you are setting up DR again on
systems that had been part of a Data Guard DR setup before being converted to standalone systems in
Step 1, the database instance names on the source and target do not need to be the same.
Upgrading DR with an HA source and non-HA Target

This section describes how to upgrade an Insight DR system when the source is an HA system and the target is a
non-HA system.
Topics include:
Prerequisites
Overview of DR upgrade with an HA Source and non-HA Target
DR upgrade with an HA Source and non-HA Target
Prerequisites
Before performing DR upgrade, perform the following steps:
Make sure that the DR Target database is currently in sync with the DR Source database.
For more details, refer to steps 28, 29 and 30 in Setting Up DR with an HA Source and non-HA Target to
check replication status
If DR setup is currently not in sync, then investigate the root cause, and do not proceed with upgrade. For
problems or questions, contact the Sonus TAC.
It is recommended to perform manual backup (using manualBackup.sh script) of EMS setup and transfer
the generated backup files to an external server for safekeeping.
This backup can be used to restore EMS configuration at a later time if needed.
Backup should be done after Step 1 (Failover) so that the DR target database is accessible before running
backup there.
For more details, refer to Insight Server Backup and Restore-DR Solaris.
Manual backup can be done while EMS is up and running, though for an HA system a manual failover may
be needed to make sure that backup can be successfully done on HA standby node.
No EMS database provisioning should be performed during the upgrade downtime window, as data

configured during upgrade may not get backed up.
Overview of DR upgrade with an HA Source and non-HA Target
The following table provides an overview of upgrading DR with an HA source and non-HA target.
Step Original HA EMS System Original non-HA Target System
1 Perform Failover to convert both into non DR systems
2 Upgrade HA EMS
3 Upgrade Standalone EMS
4 Configure DR
DR upgrade with an HA Source and non-HA Target
Perform the following to upgrade Insight on existing systems that are part of a Data Guard DR setup with an HA
source and non-HA target.
Setting Up Insight Disaster Recovery — HA Source/non-HA Target:
1. Perform a Failover on the following:

- Original HA EMS System
- Original Target System
To perform a failover, refer to "Failover-Converting DR System HA Source and Non-HA Target to Separate
non-DR Insight Servers"
Once the DR failover is completed, it is recommended to turn off Performance Management (PM)
data collection on the target EMS. This is to avoid undue load on network devices because of the
source EMS also polling the devices at the same time.
2. Upgrade HA on the following:

To perform an upgrade, refer Upgrading Insight High Availability system.
While the source EMS is getting upgraded, there may be a window of time when source EMS does
not receive any traps. During this upgrade window when the source EMS Fault Mgmt is down, the
target EMS can be used to monitor traps.
3. Upgrade original target system (currently a Standalone).

For information on upgrading the Standalone systems, refer Upgrading Insight Standalone system.
It is recommended that the DR target to be started only if the DR source upgrade is successful. If
there are issues during DR source system upgrade, do not proceed with the DR target upgrade, and
contact Sonus Support.
4. Configure Disaster Recovery on all the systems. For more details refer to Setting up DR with an HA source
and non-HA Target.

Upgrading DR with HA Source and HA Target
This section describes how to upgrade an Insight DR system when the source is an HA system and the target is an
HA system.
Topics include:
Prerequisites
Overview of DR Upgrade with an HA source and HA Target
DR Upgrade with an HA source and HA Target
Before Setting Up DR
Insight Installations or Upgrades for Existing Systems That Don’t Use Data Guard with an HA Source
Insight Upgrades from DR Systems That Use Data Guard and an HA Source
Prerequisites
Before performing DR upgrade, perform the following steps:
Make sure that the DR Target database is currently in sync with the DR Source database.
For more details, refer to steps 34, 35 and 36 in Setting Up DR with HA Source and HA Target to check
replication status
If DR setup is currently not in sync, then investigate the root cause, and do not proceed with upgrade. For
problems or questions, contact the Sonus TAC.
It is recommended to perform manual backup (using manualBackup.sh script) of EMS setup and transfer
the generated backup files to an external server for safekeeping.
This backup can be used to restore EMS configuration at a later time if needed.
Backup should be done after Step 1 (Failover) so that the DR target database is accessible before running
backup there.
For more details, refer to Insight Server Backup and Restore-DR Solaris.
Manual backup can be done while EMS is up and running, though for an HA system a manual failover may
be needed to make sure that backup can be successfully done on HA standby node.
No EMS database provisioning should be performed during the upgrade downtime window, as data
configured during upgrade may not get backed up
Overview of DR Upgrade with an HA source and HA Target
The following is an overview of upgrade with an HA source and HA target.
Step Original HA EMS System Original HA Target System
1. Perform Failover to convert both into non DR systems
2. Upgrade HA EMS
3. Upgrade Standalone EMS
4. Configure DR
DR Upgrade with an HA source and HA Target
You need to perform the following procedure to upgrade Insight using a HA Source and HA Target.

1. Perform a Failover on the following:
- Original HA Target Active System
- Original HA Target Standby System
To perform a failover, refer to Failover: Converting DR System HA Source and HA Target to Separate
non-DR Insight Servers.
Once the DR failover is completed, it is recommended to turn off Performance

Management (PM) data collection on the target EMS.
This is to avoid undue load on network devices because of the source EMS also polling
the devices at the same time.
2. Upgrade Source HA on the following:

To perform an upgrade, refer to the following sections based on your upgrade method:
Upgrading Insight HA on DR Configuration.
Or
Upgrading DR with an HA source and non-HA Target.
While the source EMS is getting upgraded, there may be a window of time when source EMS does
not receive any traps. During this upgrade window when the source EMS Fault Mgmt is down, the
target EMS can be used to monitor traps.
3. Upgrade original HA target system.

For information on upgrading the High Availability systems, refer to the following sections:
Upgrading Insight High Availability system.
Or
Upgrading DR with an HA source and non-HA Target.
It is recommended that the DR target to be started only if the DR source upgrade is successful.
If there are issues during DR source system upgrade, do not proceed with the DR target upgrade,
and contact Sonus Support.
4. Configure Disaster Recovery on all the systems. For more details refer to Setting up DR with HA Source and
HA Target.
Before Setting Up DR
Before setting up DR on a system with an HA source and HA target, all the systems need to have Insight V09.02.00.
Follow the appropriate directions for installing/upgrading Insight:
To install Insight V09.02.00 on the systems that will be part of the DR setup or to upgrade existing systems
that are not already part of a Data Guard DR setup with an HA source, see Insight Installations or Upgrades
for Existing Systems That Don’t Use Data Guard with an HA Source.
To upgrade to Insight V09.02.00 on existing systems that are part of a Data Guard DR setup with an HA
source, see Insight Upgrades from DR Systems That Use Data Guard and an HA Source . (DR setups that
use Data Guard were used on Insight V07.01.xx, V07.02.xx, and V07.03.xx, where xx is 01 or greater.)

Insight Installations or Upgrades for Existing Systems That Don’t Use Data Guard with an
HA Source
Perform the following to install Insight on the systems that will be part of the DR setup, or to upgrade existing
systems that will be part of the setup and that were not already part of a Data Guard DR setup with an HA source. (If
the systems were already part of a Data Guard DR setup with an HA source, go to Insight Upgrades from DR
Systems That Use Data Guard and an HA Source.
1. If you are upgrading, dismantle the HA-HA DR setup by performing. See Failover: Converting DR System HA
Source and HA Target to Separate non-DR Insight Servers.
2. On the source system, set up HA or upgrade the HA setup:
- If HA has not been set up on the source system, install or upgrade Insight and configure HA by performing
the tasks in Insight HA configuration.
- If HA has been set up on the source system, upgrade the HA setup by performing Upgrading Insight High
Availability system.
3. On the target system, set up HA or upgrade the HA setup:
- If HA has not been set up on the target system, install or upgrade Insight and configure HA by performing
the tasks in Insight HA configuration.
- If HA has been set up on the target system, upgrade the software version by performing Insight HA
configuration.
You must use the same database instance name on both the source and target systems when
installing or upgrading Insight for systems that have never been part of a Data Guard DR setup.
(The database instance names on the target will later be changed as part of the DR configuration.)
4. Start Insight on both the source and target systems.

5. Continue to Overview of DR Upgrade with an HA source and HA Target.
Insight Upgrades from DR Systems That Use Data Guard and an HA Source
Perform the following to upgrade Insight on existing systems that are part of a Data Guard DR setup with an HA
source, and that you will be configuring as a DR setup with an HA source and HA target:
1. Stop Insight on the target system by executing the following command as user insight:
$ ./sonusEms stop
2. Unschedule DR monitoring on the target system. As root, enter the following:
3. As root on the target system, run the convert script to change the system to standalone mode:
a. As root on the target system, run the convert script as follows:
# ./convert

Which DR mode should this system be configured to run?

a) source
b) target
c) standalone
d) quit
Please select one of the options above (default:a) [a|b|c|d]:
Answer c.
sonusEms stop will now be run to shutdown Insight!

Do you wish to continue? (default:n) [y|Y,n|N]
Answer Y.
When the convert script has finished, the following appears:
4. On the target system, change to user oracle, and enter the following:
$ cd <ORACLE_BASE>/orarepl/<ORACLE_SID>/scripts/conf
$ ./database_failover.ksh
5. Configure the target system as an Insight HA system by performing HA configuration ( Insight HA

configuration)
6. If you have IASs registered to the source system, enter the following commands on the target system to
update the Insight IP address on the IASs that were registered to the source system:
The Insight IP address on all IASs that were registered to the source system are updated to the IP address of
the target system.
7. Stop Insight on the source HA standby system (system B) by executing the following command as user
insight:
$ ./sonusEms stop

8. Unschedule DR monitoring on system B. As root, enter the following:
9. As root on system B, run the convert script to change the system to standalone mode:
a. As root on system B, run the convert script as follows:
# ./convert

a) source
b) target
c) standalone
d) quit
Answer c.
Confirm that this system is currently an HA Standby system? (default:y)

[y|Y,n|N]
Answer Y.

Answer Y.

10. Associate the reachability address of system B with all the registered devices. For an explanation of
associating an IP address with registered devices, see the Managed Device Association section.
11. As user oracle on the source HA active system (system A), export the existing database using the
<ORACLE_BASE>/backup/bin/export.sh script by entering the following commands on system A:
$ export.sh
12. On system A, the following message appears:
Press enter to accept dbimpl.

13. As user oracle, move the two exported files generated in Step 11 to the source HA standby system (system
B). Place them in:
<ORACLE_BASE>/backup/dump
14. As user oracle on system B, remove the symbolic link to init$ORACLE_SID.ora:
$ cd $ORACLE_HOME/dbs
$ rm init$ORACLE_SID.ora
15. Remove the spfile$ORACLE_SID.ora file:
$ rm spfile$ORACLE_SID.ora
16. On system B, point the database instance back to the local Oracle files:
$ cp init$ORACLE_SID.ora.<date-hour-minute-second> init$ORACLE_SID.ora
where <date-hour-minute-second> is a decimal representation of the most recent file available. For example:

$ cp init$ORACLE_SID.ora.040827150640 init$ORACLE_SID.ora
17. As user oracle on system B, issue the following commands to start the database:
$ sqlplus /nolog
SQL> startup
SQL> exit
$ lsnrctl start
18. On system B, import the database by running the cfg_import.sh using the following commands:
$ cfg_import.sh
19. On system B, the following message appears:

20. Optional — If you want to restore historical performance management data and user activity logs, enter the
following command on system B. This can take several hours and you should first determine whether this is
worth the time, since this data is only for use during the short time that system B is used to manage the
system while system A is being upgraded.
$ stats_import.sh

21. Change system B to a standalone system:
a. On system B, edit /export/home/ems/conf/HA/haConfiguration as follows:

a.
Change Mode=standby to Mode=standalone
b. Change the hostname from the hostname of the well-known address (for example, EMSHA) to the
hostname of the machine and change the IP address from the well-known IP address to the IP
address of the machine.
c. Migrate fault data from system A to system B as user insight:
i. On system B, remove the symbolic link and create the local directory:
ii. On system A as user insight:

Enter the following to create a directory to hold a backup of the fault database:
Enter the following to create a backup of the fault database and put it in
/export/home/netcool/omnibus/db.bak (the following does not contain a line break, and there
should be one space after -d):
Enter the following to copy the backup to system B (the following does not contain a line break,
and there should be one space after *.tab):
scp
/export/home/netcool/omnibus/db.bak/*.tab insight@<systemB>:/export/home/netcoo
where <systemB> is the local reachability IP address for system B.

22. Upgrade system B as follows:
a. Read Prerequisite, upgrade solaris and Database software, For more details, see Upgrading the Third
Party Software.
b. Verify that the Insight database is running by logging in as oracle and entering:
If the Insight database is running, a list of active oracle processes will be displayed. Continue to
substep c.
If the Insight database is not running, no processes will be displayed. Start the Insight database by
entering the following, and then continue to substep c:

$ sqlplus /nolog
SQL> startup
SQL> exit
c. Verify that the database listener is running:
$ lsnrctl status
If the database listener is running, the status of the listener and the status of database instances will
be displayed. Continue to substep d.
If the database listener is not running, “no listener” messages will be displayed. Start the database
listener by entering the following, and then continue to substep d:
$ lsnrctl start
d. Perform Insight HA configuration" and "Post-Installation and Post-Upgrade Tasks.

23. As user insight, start Insight on system B:
cd /export/home/ems/sonusEms start
Sonus recommends that System B as a standalone should be used only for receiving traps. Any configuration
on system B at this time will not be saved after the upgrade of both HA systems.
24. Stop Insight on the source HA active system (system A) by executing the following command as user insight:
$ ./sonusEms stop
25. Unschedule DR monitoring on system A. As root, enter the following:
26. As rooton system A, run the convert script to change the system to standalone mode:
a. As root on system A, run the convert script as follows:

# ./convert

a) source
b) target
c) standalone
d) quit
Answer c.
Confirm that this system is currently an HA Active system? (default:y)

[y|Y,n|N]
Answer Y.

Answer Y.
27. Upgrade system A by performing Upgrading Insight Standalone system.

28. As root on system A, enter the following:
#/export/home/ems/conf/HA/haResources release
29. As user insight, stop Insight on system B:

$ ./sonusEms stop
30. As user oracle on system B, shutdown the database:
$ sqlplus /nolog
SQL> exit
31. On system B, shutdown any listeners running on the system:
$ lsnrctl stop
If necessary replace the c2t0d0 in the command line with the designator for your disk.
33. Change system B back to the standby system in an HA configuration:
a. As root, enter the following command on system B to start the configureHA script.
# ./configureHA
b. The system displays the High Availability Configuration Main Menu.

c. The system displays the following:
Type s to configure a standby Insight system. The system then displays the following message:
d. The system displays the High Availability Configuration Main Menu.

d.
e. The system displays the following:
Enter the requested information for the Oracle User/

Installer....

f. The system displays the following:
You entered...
User Name: "oracle"
Group Name: "dba"

g. The system displays the following:
Enter the RAID array's fully-qualified mount point...
A default value that matches the previously configured RAID’s mount point is displayed, which you can
accept by pressing Enter.
You can also type the RAID’s mount point and press Enter (see Insight HA configuration for
establishing the RAID’s mount point).
h. The system displays the following:
Enter the RAID array's fully-qualified block device name...
A default value that matches the previously configured RAID’s device name is displayed, which you
can accept by pressing Enter.
You can also type the RAID’s device name and press Enter (see Insight HA configuration for
establishing the RAID’s device name).
i. The system displays the following:
Enter the RAID array's fully-qualified character (raw)

device name...
A default value that matches the previously configured RAID’s raw device name is displayed, which

you can accept by pressing Enter.
You can also type the RAID’s raw device name and press Enter. The “raw” device name is the same
as the device name with the addition of “r” to “dsk” (e.g. /dev/rdsk/c2t0d0s6).
j. The system displays the following:
Enter fully-qualified name of this system...
A default value that matches the previously configured well-known IP address is displayed, which you
can accept by pressing Enter.
You can also type the well-known IP address and press Enter (see Public Network Address for
establishing the well-known IP address).
k. The system displays the following:


Updating the /var/opt/oracle/oratab, so that this instance is not started

at system startup.
l. The system displays the following:

q) quit

A series of prompts appear that ask if you want to modify directory attributes. Respond Y to each
prompt.
m. The system displays the High Availability Configuration Main Menu.
n. The system displays the following:


o. The system displays the High Availability Configuration Main Menu.
Type 6 and press Enter to configure/test the SSH connection between the systems and to synchronize
the managed node information.
Testing scp
Created a zero length file on the other HA system called
/tmp/sshtestfile.14992
p. The system displays the High Availability Configuration Main Menu.

q. The system displays the following:
This step will change the IP Address on your system. Do you want to
proceed with this step? (default: yes) [y,n]

r. The system displays the following:

s. The system displays the following:
(default: no) [y,n]
Type n and press Enter.

t. The system displays the following:

Will be updating Database tables, listener file and init file with the
new IP. Will attempt to restart listener and the database instance.
Will be running netcoolsetup.ksh script to update Netcool related files
with current hostname.

u. The system displays the High Availability Configuration Main Menu.
Type q and press Enter to exit the configureHA script.
v. Enter the following commands:
34. As user insight, start Insight on system A:
35. As user insight, start system B to enable HA:
$/export/home/ems/sonusEms start
36. Sonus recommends that you disassociate the reachability address of system B (the backup system) with all
the registered devices. For an explanation of disassociating an IP address with registered devices, see
Managed Device Association.
37. Update the registration for each Insight device (see the Updating a Node section).
Managing Insight Account Names and Passwords-DR Solaris
Default Account Names and Passwords-DR Solaris

Changing the Netcool Object Server Name-DR Solaris

Procedures for Changing Passwords-DR Solaris
Default Account Names and Passwords-DR Solaris

upgrades.
root sonus
insight insight
oracle oracle
dbimpl dbimpl
system manager
admin admin

root sonusfm
Changing the Netcool Object Server Name-DR Solaris

Rollback Mechanism


Limitation
“SONUSDB”.
Procedures for Changing Passwords-DR Solaris

restrictions.

Changing Passwords-DR Solaris

The “insight” User Password on Disaster Recovery and High Availability Systems
Procedure
Insight Database Password on Disaster Recovery and High Availability Systems
Procedure
Database sys Password on Disaster Recovery and High Availability Systems
Procedure

Database system Password on Disaster Recovery and High Availability Systems
Procedure
Netcool Database User Password for the Insight_Admin_User on High Availability Systems
Procedure
Netcool Database User Password for the Root User on High Availability Systems
Procedure
EMS Keystore Password on Disaster Recovery and High Availability Systems
Procedure
Change the insight user password, if you did not use the strong password option when running the
configureJumpstart.sh or emsMigrate.sh script. This changes the insight user password from the
previous value.
expiration values.
CAUTION
procedure):

– numbers
The password:

The “insight” User Password on Disaster Recovery and High Availability Systems
You must use the same insight user password on all Insight systems that are part of a disaster recovery (DR)
system or high availability (HA) server. When you run the changeInsightPassword.sh script on the source DR
server (active source if the source is also HA) or on the active HA server, the script will give you the option of
changing the password on all the Insight servers in the system (you will be prompted for the password of the root
user for each server).
Procedure
procedure.
1. Log in as root.
Where:
password.

(Default:Y)
Enter Y.

expiration behavior. Unless you used the -v option in Step 1, the password must meet the restrictions listed in
If the server is not part of a DR or HA system, continue to Step 9.
Enter Y.

(Default:Y)
(or)
(Default:Y)
(or)
(Default:Y)

procedure):

– numbers
Insight Database Password on Disaster Recovery and High Availability Systems
When using the changeDbPassword.sh script to change the Insight database password on the source disaster
recovery (DR) system or the active high availability (HA) system, the database password will also be changed on the

target DR or standby HA system through the DR or HA monitoring code.
CAUTION
when the IAS is up by performing "Changing the Insight Agent Connection Account Password". If the Insight
database password on the IAS does not match the Insight database password on the Insight server to
which it is registered, the database user (dbimpl) will be locked out of the database, and Insight will not
function correctly. To unlock the database, run the following script: /export/home/ems/conf/unlockDb
implUser.sh
Procedure
(Default:Y)
Enter Y.
Enter the password. Unless you used the -v option in Step 1, the password must meet the restrictions listed in

5.

4.

password when the IAS is up. See Changing the Insight Agent Connection Account Password. If the Insight
% logon admin admin
success
where

4.
% exit
Insight Database Password.
following:
database password.

script.

– numbers
Database sys Password on Disaster Recovery and High Availability Systems

When using the changeSysDbPassword.sh script to change the sys database user password on the source
disaster recovery (DR) system or the active high availability (HA) system, the database password will also be
changed on the target DR or standby HA system through the DR or HA monitoring code.
Procedure


procedure):

– numbers
Database system Password on Disaster Recovery and High Availability Systems
When using the changeSystemDbPassword.sh script to change the system database user password on the
source disaster recovery (DR) system or the active high availability (HA) system, the database password will also be

changed on the target DR or standby HA system through the DR or HA monitoring code.
Procedure



– numbers
Netcool Database User Password for the Insight_Admin_User on High Availability Systems
When using the changeNetcoolDbInsightPassword.sh script to change the password on the active high
availability (HA) system, the password will also be changed on the standby HA system through the HA monitoring
code.
Procedure


command:

(Default:Y)
Enter Y.


– numbers

Netcool Database User Password for the Root User on High Availability Systems
When using the changeNetcoolDbRootPassword.sh script to change the password on the active high
availability (HA) system, the password will also be changed on the standby HA system through the HA monitoring
code.
Procedure

(Default:Y)
Enter Y.
This procedure can be used after you obtain your own SSL certificate and import it. For SSL certificate installation
information, refer Certificate Management. This procedure cannot be used with the demo site certificate that comes
with Insight.

– numbers
EMS Keystore Password on Disaster Recovery and High Availability Systems

When using the changeKeystorePassword.sh script to change the password on the source disaster recovery
(DR) system or the active high availability (HA) system, the password will also be changed on the target DR or
standby HA system through the DR or HA monitoring code.
Procedure
Enter the password.

Restrictions.


# ./jash
% logon admin admin
success

% exit
passwords.
Configuring IPv6 on DR Solaris

This section contains the procedure to migrate the EMSs in the network from IPv4 to IPv6.
Prerequisites
Enable IPv6 on the EMS Standalone Solaris Server for DR Setup

when the configured Sonus devices are migrated to IPv6. Until the configured Sonus devices are migrated to IPv6,
EMS can continue to manage all the configured devices over the existing IPv4 addresses.
The following procedure describes the procedure to enable IPv6 on the EMS Standalone server.
1. Log in as root.
# ifconfig -a
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232
index 1
inet 10.54.7.179 netmask ffffffc0 broadcast 10.54.7.191
In this example, e1000g0is the name of the interface on which IPv6 needs to be enabled.
So, create the following file:

/etc/hostname6.e1000g0
For example,
addif FD00:10:6B50:4160::33/60 up

You will see that ::1 localhost has been added as the first line.


# svcadm restart network/physical
# ifconfig -a
9. Restart the server as user root using following command:
# reboot -- -r
10. Verify that all EMS services are up after restart using the following command as user insight.
After server restart, it will take around 10 minutes for all EMS services to be up and running.
Guide.
Enable IPv6 on the EMS HA server for DR Setup

when the configured Sonus devices are migrated to IPv6. It is not necessary to migrate IPv6 address for private

interfaces. Until the configured Sonus devices are migrated to IPv6, EMS can continue to manage all the configured
The following procedure describes the procedure to enable IPv6 on the EMS HA server.
IPv6 is not supported for private interfaces.
1. Log in as root on both the active and standby systems.

where the <interface name> is the name of the reachability interface used on the HA system. For more
information, see table Reachability Interface and IP Address.
For example, in T5220 the file name will be /etc/hostname6.e1000g0.
For example,
addif FD00:10:6B50:4160::33/60 up

4. Stop EMS on both the Active and Standby systems and then release resources.
Perform the following procedure:
a. Identify the current Active and Standby states of the servers by executing the following commands as
user root:
# /export/home/ems/conf/HA/hamgmt getState | grep Actual
b. Login as user insight and stop insight in Standby (first) and then, on Active by executing the
following commands:
# su - insight
$ exit
c. Login as user root and release the resources in Active (first) and then on Standby by executing the
following command:
5. Plumb the primary and secondary interfaces using the following command:

5.
# ifconfig <interface name> plumb
For more information, see table Public Network Interfaces and IP Addresses.
For example, in T5220 to plumb e1000g1, use the following command:
6. Login as root and run the configureHA script.

# ./configureHA
8. The system displays the HA Configuration Menu.

IP Multipathing is used to provide network interface resiliency. You must

provide the appropriate information to configure this functionality.
IP Multipathing uses two physical network interfaces that are "grouped"
together. They share a logical network interface which uses the "well known"
IP Address that all managed elements and client systems use to access the
Insight product.
The two physical network interfaces that will be used for IP Multipathing must
already be plumbed and attached to the network before continuing. If they are
not plumbed and attached, please do so before continuing.
The Insight reachability address is used on the standby system to communicate
with any Insight systems that are monitoring it. The reachability address must
be on its own dedicated physical interface.
e1000g0
e1000g1
e1000g2
nxge0
nxge1

Which interface will be the primary? [e1000g0 e1000g1 e1000g2 nxge0 nxge2] :

Enter the primary interface.
Which interface will be the secondary? [e1000g0 e1000g2 nxge0 nxge2] :
Enter the secondary interface.

What is the name of the IP Network Multipathing group. (default: HA-PUB-GRP):

[y|n]:

10.54.8.72
fd00:10:6b50:4190::8
What is the test IPv6 address prefix length for the primary
LAN interface? (Default:128):60

interface?: fd00:10:6b50:4190::9
What is the test IPv6 address prefix length for the secondary
LAN interface? (default:128):60

What is the well-known IPv4 address on the LAN?:10.54.8.78
What is the well-known IPv6 address on the
LAN?:fd00:10:6b50:4190::e
What is the well-known IPv6 address prefix length?
(default:128):60

interface?:fd00:10:6b50:4190::d
What is the "dummy" IPv6 address prefix length?
(default:128):60
What is the IPv4 reachability address?:10.54.8.71

What is the IPv6 reachability address?:fd00:10:6b50:4190::7
active Netra T5220 system in Public Network Setup for EMS HA DR:

Primary Interface Test IPv6 Address:"fd00:10:6b50:4190::8"
Primary Interface Prefix Length:60"
Secondary Interface Test IPv6 Address:
"fd00:10:6b50:4190::9"
Secondary Interface Prefix Length:"60"
Well known IPv6 Address Of The Group:"fd00:10:6b50:4190::e"
Well known Address Prefix Length: "60"
Dummy IPv6 Address Of The Group:"fd00:10:6b50:4190::d"
Dummy Address Prefix Length:"60"
Reachability IPv4 Address: "10.54.8.71"
Reachability IPv6 Address:"fd00:10:6b50:4190::7"


20.
Provide all the requested IP addresses.

You can provide upto 4 such addresses.
Peer Keep Alive IP Address 3 (RETURN to stop) :
Alives.
What is the peer's reachability address : 10.54.8.74
Alives.
What is the peer's reachability address : fd00:10:6b50:4190::0a
You entered:
Peer's Reachability IPv6 Address: fd00:10:6b50:4190::0a

Type q and press Enter.
22. Start EMS on both the Active and Standby systems by performing the following procedure:
a. Identify the configured Active and Standby states of the servers by executing the following commands
as user root. If the output displays as ACTIVE, then that server is identified as Active server, else
Standby:
# /export/home/ems/conf/HA/hamgmt getState | grep Configured
b. On Active, start Insight as user ‘insight’:
c. On Active, check status of Insight
Expected output: Lists all processes as ‘running’ and current HA state is shown as ACTIVE.
d. On Standby, start Insight as user ‘insight’:
e.

e. On Standby, check status of Insight
Expected output: Lists all processes as ‘running’ and current HA state is shown as STANDBY.
f. Exit from user insight.
$ exit
23. Open EMS GUI on active system and re-register devices with the IPv6 management client IP Address. See
Re-register the Device with the IPv6 management address from the EMS Node Registration Window-DR
Setup.
Node Registration Window-DR Setup


4. Click Register.
Migrating the StorageTek RAID from IPv4 to IPv6-DR Setup

Once the hosts connected to RAID are migrated to IPv6, you can migrate the RAID to IPv6. Follow the procedure
below to migrate the StoregTek RAID to IPv6.
2.

controllers.
3. Press uppercase S within five seconds when the following prompt appears:
Press within 5 seconds: <S> for Service Interface <BREAK> for baud rate
4. Enter the password within 60 seconds at the following prompt:
Enter Password to access Service Interface (60 sec timeout):

==============================
Q) Quit Menu
Enter Selection:2
Enter 2.
7. Once you select option 2, skip the IPv4 part as it is already configured:
Enable IPv4? (Y/N) : y

Configure using DHCP ? (Y/N): n
Press '.' to clear the field;
Press '-' to return to the previous field;
IP Address if0 : 10.54.72.73
Subnet Mask if0 : 255.255.255.0
Gateway IP Address if0 : 10.54.72.1
NO change in IP Configuration
Enable IPv6 (Y/N)?
Enter Y.
9. Enter N for Stateless Address Autoconfiguration:

Configure using Stateless Address Autoconfiguration? (Y/N): n
10. Accept default value for IPv6 Local Address:
IPv6 Local Addr if0 :

Current Configuration :::
New Configuration :::1
11. Enter the IPv6 address of the server as the IPv6 Routable Address:
IPv6 Routable Addr if0 :

New Configuration :
12. Enter the IPv6 address of the router (gateway) as the IPv6 Routable Address:
IPv6 Router Addr if0 :

New Configuration
13. Verify if the IP addresses are correct.

Local IPv6 Address : ::1
14. Enter 'y' after verifying the IPs. Following confirmation message will be displayed:
Network Configuration successfully changed.
15. Reset the controller for changes to take effect:
Reboot to have the settings take effect? (Y/N) y
16. Register the storageTek array using IPv6 address from the host connected to RAID using the following
command:

16.
sscs add -i <IPv6 address> registeredarray
17. Repeat Steps 1 through 15 for the other RAID disk array controller.
Common Administrative Tasks-DR Solaris
Insight Server Administration-DR Solaris

Insight Server Backup and Restore-DR Solaris
Insight Server Database Administration-DR Solaris
Netcool Configuration-DR Solaris
High Availability Insight Server Administration
Disaster Recovery Insight Server Administration
Account Management-DR Solaris
Uninstalling Sonus Insight-DR Solaris
Disk Mirroring-DR Solaris
Insight Server Administration-DR Solaris


Expected output:

PKGINST: SONSems
NAME: Sonus Insight
ARCH: sparc
pathnames 7
linked files 1780
directories 3288
$ ./sonusEms status
When you run ./sonusEms status on an HA system, the information displayed in Checking the HA Status is also
displayed.
$ ./sonusEms start

HA related messages that appear during the sonusEms start are shown in "HA Messages During sonusEms
start".
# ./sonusEms -help
$ ./sonusEms stop
HA related messages that appear during the sonusEms stop are shown in " HA Messages During sonusEms stop"
procedure. Instead, use "Changing the host name for Insight without Changing the IP Address".



b. Respond y.

c/hosts
7. Start Insight.
8. Disassociate all registered nodes with the old IP address (see “Managed Device Association” in the
Insight Administration chapter of the Insight EMS User Guide).
procedure. Instead, use "Changing the IP Address of Insight".




Respond y.


changed.
Insight Server Backup and Restore-DR Solaris

backup files.

EMS Solaris

release.
Release.
Release.

not stable.
Release.
Release.
High-level Steps:
sustaining release.
System Backup

1. (Optional) Kickstart the EMS Standalone (SA) or HA Solaris system with respective EMS Release from which
backup was taken, if the EMS Solaris system is not stable. For more details, about EMS Release from which
you want to kickstart, refer the above Table.
2. Log in as root.
directory.

or
or
file names:
CAUTION
# ./emsMigrate.sh
used.
10.

the following:
#.)
and #.)

Enter N.

Passwords


Lowercase letters
Uppercase letters
Numbers
Special characters
Insight Server Database Administration-DR Solaris


$ sqlplus /nolog
SQL> startup
SQL> exit

2.
$ sqlplus /nolog
SQL> exit
$ lsnrctl start
$ lsnrctl stop
$ lsnrctl status
displayed.

system restore, see Insight Server Backup and Restore-DR Solaris.
strategy.
$ export_manual.sh
database.
errors.
CAUTION
to shut down Sonus Insight refer to the procedure, Stopping the Insight Server.

3.
database.
following:
following:
Netcool Configuration-DR Solaris

On this page:


parameters.
default.
Insight Server Administration-DR Solaris. If you want to start, stop, or check the status of the Netcool processes
separately from the Insight server, use the following commands.

2.
High Availability Insight Server Administration

This section contains the following high availability (HA) Insight server administrative tasks:
HA Manual Failover
HA Logs
Location of Logs
HA Audit Log
Agent Trace Log
RAID Lock Mechanism
Overview
Prerequisite
HA Manual Failover
It may become necessary in a HA system, either as a planned event or due to an incomplete automatic failover, to
initiate a manual failover from the active to the standby system. Perform the following to initiate a failover:
1. As user insight, enter the following:

$ ./sonusEms failOver
The success or failure of the failover is displayed. The possible messages are:
"Operation successfully completed."

"Error connecting to agent."
"Error connecting to agent on the peer system."
"Fail over is aborted because the peer system is in UNKNOWN state."
"Active failed to become Standby because "ReleaseResources" failed. Fail over
did not complete."
"Standby failed to become Active because "TakeoverResources" failed. Fail over
did not complete."
"Standby failed to become Active because "sonusEms start" failed. Fail over
did not complete."
If the failover was not successful, contact the Sonus TAC.
To check the HA status of an Insight server, perform the following procedure.
When you run sonusEms status, you will also see the information described in Step 3.
1. Login to the system as root.

2. Navigate to the HA directory as follows:
# ./hamgmt getState
The actual state and the configured state of the server are displayed. The possible states are:
UNKNOWN
ACTIVE
STANDBY
ACTIVE_INTENT (attempted to become active but failed because the required resources were not
available)
STANDBY_INTENT (attempted to become standby but failed because the presently owned resources
could not be relinquished)
The following information about resources held by the system will also be displayed:

Whether the logical IP is published on this system.
Whether the RAID is mounted by this system.
Whether database processes are running on this system.
During a successful sonusEms start on the active system, the following messages are displayed:
This system is the Active HA system. The Insight processes will now be started.
During a successful sonusEms start on the standby system, the following messages are displayed:
This system is the Standby HA system. Only some of the Insight processes will be
started.
During an unsuccessful sonusEms start on the active or standby system, the following HA issues can be displayed:
Failed to contact Fail over control!

The system failed to become Active because "TakeoverResources" failed. Its state is
set to UNKNOWN.
"Fail over control has not been initialized because the system is not in UNKNOWN
state."
"Failed to initialize Fail over control!"
During a sonusEms stop on the active or standby system, the following messages are displayed:

Stopping HA Fail over control now.
Fail over control has been stopped.
HA Logs

Location of Logs
The ha_audit_log and the agent_trace_log files are located under the directory <agent_home>/logs.
The <agent_home> directory is the location in which the Sonus agent is installed. You can find this name by
typing:
# echo `pkgparam SONScomm BASEDIR`/sonusComm
HA Audit Log
The ha_audit_log contains logging statements for the time of HA transitions, the previous HA state of the
system, and the current HA state of the system.
Agent Trace Log
The agent_trace_log contains logging statements for FailOverControl, heartbeat, system check, and
auto-starting related issues.
RAID Lock Mechanism
To prevent an Oracle data corruption, a new functionality RAID Lock Mechanism is added. Any server that is active,
locks the RAID with its signature and unlocks it during switchover. The server cannot mount the RAID, if it is locked
by the peer.
To reboot one of the HA servers, use the following command:
# reboot
The failover successfully happens after the rebooted active server comes up. The RAID lock is released after the
server comes up.
To shutdown the HA servers, use the following command:
# shutdown

If the active server is shutdown, it will not trigger a switchover, because the active server still retains the
lock. To shutdown the active server, first the switchover has to be triggered and then the Node has to be
shutdown.
To remove a Node from a cluster, use the following command:
/opt/sonus/ems/conf/HA/RAC/hamgmt shutdownNode
Overview
This section describes how to convert either the active or standby system to a standalone system by running
configureHA and selecting option 8.
This process points the database instance to the local database files and sets the IP address of the system to the
previously configured reachability address for the system.
Prerequisite
Before performing the procedure Running configure HA to convert an HA system to Standalone, place database
dump files on the system by performing the following procedure:
Perform the following procedure to create Database Dump File:
1. As user oracle on system A (the active system), export the existing database by entering the following
commands on system A:
$ ./export.sh
2. If you are converting the standby system (system B) to standalone, then as user oracle, move the two
exported files generated in Step 1 to system B. Place them in:<ORACLE_BASE>/backup/dump
Perform the following procedure to create Netcool Dump Files:
1. Perform the following steps on the Active System as user insight.

a. Enter the following command to create a directory to hold a backup of the fault database

1.
a.
and place it in the below path:
The path does not contain a line break and there should be one space after -d
Perform the following procedure to convert an HA system into a standalone EMS:
1. Run haMigrateFiles.sh script on Active system to move the reports and PM files from RAID.
Ensure that the RAID is mounted before running haMigrateFiles.sh.
a. Login as user insight on Active system and stop EMS.
./sonusEms stop
b. Login as root in the Active system and enter the following commands to start the
haMigrateFiles.sh script.
From the list of options, select 4 “Migrate All back to Standalone

2. Run haMigrateFiles.sh script on Standby system to move the reports and PM files from RAID.
a. Login as user insight on Standby system and stop EMS.
./sonusEms stop
b. Release resources on Active system, login as root in Active system and release resources.
c.

c. Takeover resources on Standby system, login as root in Standby system and takeover resources.
d. Login as root in the Standby system and enter the following commands to start the haMigrateFiles.sh
script.
e. Release resources on Standby system, login as root in Standby system and release resources.
From the list of options, select 4 “Migrate All back to Standalone”
3. Takeover resources on Active system, login as root in Active system and takeover resources:
4. As root on the system that you are converting to standalone, enter the following command to start the
configureHA script:
# ./configureHA
5. The system displays the HA configuration Main menu:

This option will convert your system to standalone mode. Do you want to
proceed? (default: n) [y,n]

7.
Have you copied Oracle dump files in /export/home/oracle/backup/dump dir?

(default: no) [y,n]
Importing the database does not import historical performance management data
and user activity logs because this may take several hours to complete.
Enter yes if you wish to do the stats import, or no to skip importing the
stats.? (default: no) [y,n]
If you want to restore historical performance management data and user activity logs (this can take several
hours), type Y and press enter. Otherwise, type n and press Enter.
You selected to import historical performance management data and user

You selected to not import historical performance management data and user
(default: no) [y,n]
To notify all the IASs that were registered to the HA system of the new standalone system’s IP address, type
y and press Enter. Otherwise, type n and press Enter.
You selected to notify the registered IAS systems. Is that correct? (default:
no) [y,n]
You selected to not notify the registered IAS systems. Is that correct?
(default: no) [y,n]

12.
Do you wish to import a backup of a Fault database or create a new one?

[import,create]:
Enter either import or create.
13. If you entered create in Step 12, skip to Step 16.

If you entered import in Step 12 and you are converting a standby system to standalone, continue to Step 14.
If you entered import in Step 12 and you are converting an active system to standalone, skip to Step 16.
14. Migrate fault data from the active system to the standby system as follows:
a. Open a second window on the standby system and as user insight, remove the symbolic link and
create the local directory:
b. Copy the files created on, see Creating Netcool Dump Files, to Standby.
For example,
scp /export/home/netcool/omnibus/db.bak/*.tab
insight@<systemB>:/export/home/netcool/omnibus/db/SONUSDB
where <systemB> is the local reachability IP address for the standby system.
(the above example does not contain a line break, and there should be only one
space after *.tab)
15. If you entered import in Step 12, the system displays the following:
To import a saved Netcool database to the local system, you need to have
table_store.tab and master_store.tab files.
Do you have access to table_store.tab and master_store.tab files? (default:
no) [y,n] y

16. When the conversion to standalone is complete, the following is displayed:

This system is configured as Standalone. Sonus Insight server should be
started as user 'insight'.
3) Input the IP Multipath and Insight Reachability information.
q) quit
17. As user insight, start Insight:
Ignore the following step if the procedure is performed as part of Disaster Recovery Upgrade.
18. Rediscover all the managed nodes:

a. As a user with administrative privileges, go to the Node tab in the Insight Administration page.
b. Select a node from the Sonus Managed Nodes list, and click the Discover button.
Disaster Recovery Insight Server Administration

This section describes about various switchover and failover scenarios:
Switchover
A switchover is a planned role reversal between the production database and the standby database to avoid
downtime during scheduled maintenance on the production system or to test readiness for future role transitions. A
switchover guarantees no data loss. During a switchover, the production database and source system transition to a
standby role, and the standby database and target system transition to the production role.
Failover
A manual failover is performed when the production database fails and the standby database and target system are
transitioned to take over the production role, allowing business operations to continue. The user must run the
failover procedure in order for a failover to take place.
This section details the following switchover and failover scenarios in a disaster recovery (DR) Insight server
administrative tasks:

Switchover of a DR System Containing HA Source and non-HA Target
Overview
This section describes how to change the current source system into a target and change the current target system
into a source within a DR system (switchover). This scenario assumes that the current source is an HA system, the
current target is non-HA, and that DR is set up and running on the source and target systems.
The table 'Swithover of HA Source and non-HA Target' gives an overview for switching the HA source system and
the non-HA target system. The detailed steps are in "Procedure".
Table 1: Switchover of HA Source and non-HA Target
Step Original HA Source Active System Original HA Source Standby System Original Target System
1 (Start of maintenance window.)
Stop Insight.
3 Run the convert script to change the target system to source mode.
Stop Insight.
6 Run the convert script to change the source

standby system to target mode.
Stop Insight.

active system to target mode.
10 Run source_switchover_step1.ksh.
11 Run target_switchover_step1.ksh.
14 Run create_archivelog.ksh and sequence_num_status.ksh to verify that

the sequence numbers are incrementing.
18 Start Insight.
Note: This is now the new source.

19 Start Insight.
Note: This is now the new target active.
20 Start Insight.
Note: This is now the new target standby.
Procedure
Use the following procedure to switch the HA source and non-HA target systems (switchover).
Table 2: Switchover of HA Source and non-HA Target
Step System Action
1 Original target Stop Insight on the original (current) target system by executing the following command as user insight:
$ ./sonusEms stop
2 Original target Unschedule DR monitoring on the original target system. As root, enter the following:
3 Original target As root on the original target system, run the convert script to change the system to source mode:
a. As root on the original target system, run the convert script as follows:
# ./convert

a) source
b) target
c) standalone
d) quit
Answer a
Answer Y.
4 Original source standby Stop Insight on the original source standby system by executing the following command as user insight:
For Insight V09.00.00 release and earlier, enter the following command:
$ ./sonusEms stop
5 Original source standby Stop FM Trap Receiver process by executing the following command as user insight.
$ ./sonusEms stop fmReceiver
You can check the status by executing the following command as user insight.
$./sonusEms status fmReceiver
6 Original source standby Unschedule DR monitoring on the original source standby system. As root, enter the following:

7 Original source standby As root on the original source standby system, run the convert script to change the system to target mode:
a. As root on the original source standby system, run the convert script as follows:
# ./convert

a) source
b) target
c) standalone
d) quit
Answer b.
Answer Y.
Answer Y.
8 Original source active Stop Insight on the original source active system by executing the following command as user insight:
$ ./sonusEms stop
9 Original source active Stop FM Trap Receiver process by executing the following command as user insight:
$./sonusEms stop fmReceiver
Check the status by executing the following command as user insight.
10 Original source active Unschedule DR monitoring on the original source active system. As root, enter the following:
11 Original source active a. As root on the original source active system, run the convert script as follows:
# ./convert

a) source
b) target
c) standalone
d) quit
Answer b.
Answer Y.
Answer Y.
12 Original source active On the original Source Active, change the user as insight, and enter the following:
$ cd /export/home/sonusComm/bin/
$ ./sonusAgent stop
13 Original source active On the original source active system, change to user oracle, and enter the following:
$ ./source_switchover_step1.ksh

14 Original Target On the original target system, change to user oracle, and enter the following:
$ ./target_switchover_step1.ksh
15 Original source active On the original source active system as user oracle, enter the following:
16 Original target On the original target system as user oracle, enter the following:
The source and target systems have been switched. Steps "17", "18", and "19" verify that replication is functioning.
17 New source (original target) On the new source (original target) system as user oracle, enter the following:
Results spooled to /export/home/oracl10.2.0.3e/orarepl/SIDB/logs/conf/create_archivelog.log

The environment is:
ORACLE_SID=SIDB
System altered.
18 New source (original target) On the new source (original target) system as user oracle, enter the following:
SOURCE_SEQUENCE
---------------
172
------------------- ------------------
172 171
19 New source (original target) On the new source (original target) system as user oracle, perform the following:


c. Check to see if the SOURCE_SEQUENCE, TARGET_ARCHIVED_SEQ, and TARGET_APPLIED_SEQ values have all incremented from
those displayed in Step "18".
If all of the values have incremented from those displayed in Step "18", go to Step "20".
If any of the values have not incremented from those displayed in Step "18", repeat Step "19", substeps "a", "b", and "c" every few minutes
until all the values have incremented. It is not unusual for this to take 15 minutes.
If you repeat substeps "a", "b", and "c" for 15 minutes and any of the values have not incremented, contact the Sonus TAC.
20 New target active (original Schedule DR monitoring on the new target active (original source active) system. As root, enter the following:
source active)
21 New target standby Schedule DR monitoring on the new target standby (original source standby) system. As root, enter the following:
(original source standby)

22 New source (original target) Schedule DR monitoring on the new source (original target) system. As root, enter the following:
23 New target active (original On the new Target Active (original Source Active), change user to insight, and enter the following:
source active)
$ ./sonusAgent start
24 New source (original target) Start Insight on the new source (original target) system by logging in as insight and executing the following commands (this system then becomes
the new source):
$ ./sonusEms start
25 New target active (original Start Insight on the new target active (original source active) system by logging in as insight and executing the following commands (this system then
source active) becomes the new target active):
$ ./sonusEms start
26 New target standby Start Insight on the new target standby (original source standby) system by logging in as insight and executing the following commands (this system
(original source standby) then becomes the new target standby):
$ ./sonusEms start
27 If you have IASs registered to the original source system, continue to Step "28".
If you do not have any IASs registered to the original source system, this procedure is complete.
28 New source (original target) On the new source (original target) system, enter the following commands to update the Insight IP address on the IASs that were registered to the
original source system:
The Insight IP address on all IASs that were registered to the original source system are updated to the IP address of the new source system.
Switchover of a DR System Containing HA Source and HA Target
Table 1: Switchover of HA Source and HA Target
Step Original HA Source Original HA Source Original HA Target Active Original HA Target
Active System Standby System System Standby System
Prerequisites: Install/upgrade Insight V09.03.00 HA system Prerequisites: Install/upgrade Insight V09.03.00 HA

and start Insight system and start Insight
1 (Start of
maintenance
window.)
Stop Insight.
2 Unschedule DR
monitoring.
3 Run the convert script

to change the target
system to source
mode.
4 (Start of maintenance window).

Stop Insight.

5 Unschedule DR Monitoring
6 Run the convert script to change

the target active system to
source.
7 (Start of maintenance
window).
Stop Insight.
8 Unschedule DR
Monitoring

to change the source
standby system to
target mode.
window).
Stop Insight.
12 Run the convert script to

change the source active
system to target mode.
13 Run
target_switchover_step2.ksh.
Run
15 Run
source_switchover_step2.ksh.
16 Run
17 Run create_archivelog.ksh and

sequence_num_status.ksh to
verify that the sequence numbers
are incrementing.
19 Run
configureDrMonitoring.
21 Run
configureDrMonitoring.

22 Start Insight.
Note: This is now the new source

active.
23 Start Insight.
(End of maintenance
window.)
Note: This is now the

new source standby.
24 Start Insight.
(End of maintenance
window.)
Note: This is now the new

target active.
25 Start Insight.
(End of maintenance
window.)

new target standby.
Overview
into a source within a DR system (switchover). This scenario assumes that the current source is an HA system, the
current target is an HA system, and that DR is set up and running on the source and target systems.
The 'Switchover of HA Source and HA Target' table gives an overview for switching the HA source system and the
HA target system.
Procedure
Use the following procedure to switch the HA source and HA target systems (switchover).
Table 2: Switchover of the HA Source and HA Target
Step System Action
1 Original target standby Stop Insight on the original (current) target standby system by executing the following command as user insight:
$ ./sonusEms stop

2 Original target standby Stop FM Trap Receiver process by executing the following command as user insight:
Check the status by executing the following command as user insight:
3 Original target standby Unschedule DR monitoring on the original target system. As root, enter the following:
4 Original target standby As root on the original target standby system, run the convert script to change the system to source mode:
a. As root on the original target standby system, run the convert script as follows:
# ./convert

a) source
b) target
c) standalone
d) quit
Answer a

Answer Y.
5 Original target active Stop Insight on the original source standby system by executing the following command as user insight:
$ ./sonusEms stop
6 Original target active Stop FM Trap Receiver process by executing the following command as user insight.
7 Original target active Unschedule DR monitoring on the original target active system. As root, enter the following:

8 Original target active As root on the original target active system, run the convert script to change the system to source mode:
a. As root on the original target active system, run the convert script as follows:
# ./convert

a) source
b) target
c) standalone
d) quit
Answer a.
Answer Y.
Answer Y.
9 Original source standby Stop Insight on the original source standby system by executing the following command as user insight:
$ ./sonusEms stop
10 Original source standby Stop FM Trap Receiver process by executing the following command as user insight:
11 Original source standby Unschedule DR monitoring on the original source standby system. As root, enter the following:
12 Original source standby As root on the original source standby system, run the convert script to change the system to target mode:
a. As root on the original source active system, run the convert script as follows:
# ./convert

a) source
b) target
c) standalone
d) quit
Answer b.
Answer Y.
Answer Y.
13 Original source active On the original Source Active, change the user as insight, and enter the following:
$ ./sonusAgent stop

14 Original source active Stop insight on the original source active system, by executing the following command:
15 Original source active Stop FM Trap Receiver process by executing the following command as user insight::
16 Original source active Unschedule DR monitoring on the original source active system.
As root, enter the following:
17 Original source active As root on the original source active system, run the convert script to change the system to target mode:
# ./convert

a) source
b) target
c) standalone
d) quit
Answer b.
Answer Y.
Answer Y.
18 Original source active On the original source active system, change to the user oracle, and enter the following:
19 Original target active On the original target active system, change to user oracle, and enter the following:
20 Original source active On the original source active system as user oracle, enter the following:
21 Original target active On the original target active system as user oracle, enter the following:

22 New source active (original On the new source active (original target active) system as user oracle, enter the following:
target active)

The environment is:
ORACLE_SID=SIDR
System altered.
target active)
SOURCE_SEQUENCE
---------------
172
------------------- ------------------
172 171
24 New source active (original On the new source active (original target active) system as user oracle, perform the following:
target active)

25 New target active (original On the new Target Active (original Source Active), change user to insight, and enter the following:
source active)
$ ./sonusAgent start
26 New target active (original Schedule DR monitoring on the new target active (original source active) system. As root, enter the following:
source active)
27 New target standby Schedule DR monitoring on the new target standby (original source standby) system. As root, enter the following:
(original source standby)
28 New source active (original Schedule DR monitoring on the new source active (original target active) system. As root, enter the following:
target active)
29 New source standby Schedule DR monitoring on the new source standby (original target standby) system. As root, enter the following:
(original target standby)
30 New source active (original Start Insight on the new source active (original target active) system by logging in as insight and executing the following commands (this system then
target active) becomes the new source active):
$ ./sonusEms start

31 New source standby Start Insight on the new source standby (original target standby) system by logging in as insight and executing the following commands (this system
(original target standby) then becomes the new source standby):
$ ./sonusEms start
32 New target active (original Start Insight on the new target active (original source active) system by logging in as insight and executing the following commands (this system then
source active) becomes the new target active):
$ ./sonusEms start
33 New target standby Start Insight on the new target standby (original source standby) system by logging in as insight and executing the following commands (this system
(original source standby) then becomes the new target standby):
$ ./sonusEms start
35 New source active (original On the new source active (original target active) system, enter the following commands to update the Insight IP address on the IASs that were
target active) registered to the original source system:
Switchover of a DR System Containing non-HA Source and HA Target
Overview
into a source within a DR system (switchover). This scenario assumes that the current source is a non-HA system,
the current target is HA, and that DR is set up and running on the source and target systems.
The following table gives an overview for switching the non-HA source system and the HA target system. The
detailed steps are in "Switchover of the non-HA Source and HA Target".
Table 1: Switchover of Source and HA Target
Step Original Source System Original HA Target Active System Original HA Target Standby System
Stop Insight.
3 Run the convert script to change the target

standby system to source mode.
Stop Insight.
6 Run the convert script to change the target active system to source mode.
Stop Insight.

14 Run create_archivelog.ksh and sequence_num_status.ksh to verify that the

sequence numbers are incrementing.
18 Start Insight.
Note: This is now the new source active.
19 Start Insight.
Note: This is now the new source standby.
20 Start Insight.
Note: This is now the new target.
Procedure
Use the following procedure to switch the source and target systems (switchover) when the target is an HA system.
Table 2: Switchover of the non-HA Source and HA Target
Step System Action
1 Original target standby Stop Insight on the original (current) target standby system by executing the following command as user insight:
$ ./sonusEms stop
2 Original target standby Stop FM Trap Receiver process by executing the following command as user insight:
Check the status by executing the following command as user insight

3 Original target standby Unschedule DR monitoring on the original target standby system. As root, enter the following:
4 Original target standby As root on the original target system, run the convert script to change the system to source mode:
# ./convert

a) source
b) target
c) standalone
d) quit
Answer a
Answer Y.
Answer Y.
5 Original target active Stop Insight on the original source standby system by executing the following command as user insight:
$ ./sonusEms stop
6 Original target active Stop FM Trap Receiver process by executing the following command as user insight.
7 Original target active Unschedule DR monitoring on the original source standby system. As root, enter the following:
8 Original target active As root on the original target active system, run the convert script to change the system to source mode:
a. As root on the original target active system, run the convert script as follows:
# ./convert

a) source
b) target
c) standalone
d) quit
Answer a.
Answer Y.
Answer Y.
9 Original source Stop Insight on the original source system by executing the following command as user insight:

10 Original source Unschedule DR monitoring on the original source system. As root, enter the following:
11 Original source As root on the original source system, run the convert script to change the system to target mode:
a. As root on the original source system, run the convert script as follows:
# ./convert

a) source
b) target
c) standalone
d) quit
Answer b.
Answer Y.
12 Original source On the original source active system, change to user oracle, and enter the following:
13 Original Target active On the original target active system, change to user oracle, and enter the following:
14 Original source On the original source system as user oracle, enter the following:
15 Original target active On the original target active system as user oracle, enter the following:
target active)

The environment is:
ORACLE_SID=SIDB
System altered.
target active)
SOURCE_SEQUENCE
---------------
172
------------------- ------------------
172 171

18 New source active (original On the new source active (original target active) system as user oracle, perform the following:
target active)

19 New target (original source) Schedule DR monitoring on the new target (original source) system. As root, enter the following:
20 New source active (original Schedule DR monitoring on the new source standby (original target standby) system. As root, enter the following:
target standby)
21 New source standby Schedule DR monitoring on the new source standby (original target standby) system. As root, enter the following:
(original target standby)
22 New source active (original Start Insight on the new source active (original target active) system by logging in as insight and executing the following commands (this system then
target active) becomes the new source active):
$ ./sonusEms start
23 New source standby Start Insight on the new source standby (original target standby) system by logging in as insight and executing the following commands (this system
(original target standby) then becomes the new source standby):
$ ./sonusEms start
24 New target (original source Start Insight on the new target (original source) system by logging in as insight and executing the following commands (this system then becomes
) the new target):
# cd /export/home/ems
# ./sonusEms start
26 New source active (original On the new source active (original target active) system, enter the following commands to update the Insight IP address on the IASs that were
target active) registered to the original source system:
Switchover of a DR System Containing non-HA Source and non-HA Target
Overview
into a source within a DR system (switchover). This scenario assumes that the current source and target are non-HA
systems and that DR is set up and running on the source and target systems.
The following table gives an overview for switching the non-HA source system and the target system. The detailed
steps are in Table 2: Switchover of non-HA Source and non-HA Target.

Table 1: Switchover of non-HA Source and non-HA Target
Stop Insight.
3 Run the convert script to change the target system to source mode.
Stop Insight.

11 Run create_archivelog.ksh and sequence_num_status.ksh and make a note of the SOURCE_SEQUENCE, TARGET_ARCHIVED
_SEQ, and TARGET_APPLIED_SEQ values.
12 Run create_archivelog.ksh and sequence_num_status.ksh to verify that the sequence numbers are incrementing.
15 Start Insight.
16 Start Insight.
Note: This is now the new source active.
17 Update the EMS IP address on the IASs that were registered to the original source system.
Procedure
Use the following procedure to switch the source and target systems (switchover) when both the source and the
target are non-HA systems.
Table 2: Switchover of non-HA Source and non-HA Target
Step System Action

1 Original target Stop Insight on the original (current) target system by executing the following command as user insight:
$ ./sonusEms stop
2 Original target Unschedule DR monitoring on the original target system. As root, enter the following:
3 Original target As root on the original target system, run the convert script to change the system to source mode:
# ./convert

a) source
b) target
c) standalone
d) quit
Answer a

Answer Y.
4 Original source Stop Insight on the original source system by executing the following command as user insight:
5 Original source Unschedule DR monitoring on the original source system. As root, enter the following:
6 Original source As root on the original source system, run the convert script to change the system to source mode:
# ./convert

a) source
b) target
c) standalone
d) quit
Answer b.

Answer Y.
7 Original source On the original source system, change to user oracle, and enter the following:
8 Original target On the original target system, change to user oracle, and enter the following:
9 Original source On the original source system as user oracle, enter the following:

10 Original target On the original target system as user oracle, enter the following:
11 New source On the new source (original target ) system as user oracle, enter the following:
(original target )
New source On the new source (original target) system as user oracle, enter the following:
(original target)
12 New source On the new source (original target) system as user oracle, perform the following:
(original target)

c. Check to see if the SOURCE_SEQUENCE, TARGET_ARCHIVED_SEQ, and TARGET_APPLIED_SEQ values have all incremented from those
displayed in Step "11".
If any of the values have not incremented from those displayed in Step "11", repeat Step "12", substeps "a", "b", and "c" every few minutes until all
the values have incremented. It is not unusual for this to take 15 minutes.
13 New target Schedule DR monitoring on the new target (original source) system. As root, enter the following:
(original source)
14 New source Schedule DR monitoring on the new source(original target) system. As root, enter the following:
(original target)
15 New source Start Insight on the new source (original target) system by logging in as insight and executing the following commands (this system then becomes the new
(original target) source):
$ ./sonusEms start
16 New target Start Insight on the new target (original source) system by logging in as insight and executing the following commands (this system then becomes the new
(original source) target):
$ ./sonusEms start
If you have IASs registered to the original source system, continue to Step "19".
17 New source On the new source (original target) system, enter the following commands to update the Insight IP address on the IASs that were registered to the original
(original target) source system:
Failover-Converting DR System HA Source and Non-HA Target to Separate non-DR Insight

Servers
Overview

This section describes how to make the target system take over as a non-DR Insight server that replaces the current
DR system (failover). This scenario assumes that the current source is an HA system, the current target is a non-HA
system, and DR is set up and running on the source and target systems.
This section also describes how to put the original source system into operation as an additional non-DR system if
the system is still serviceable. This additional non-DR system should not be used to concurrently manage the same
devices that the original target manages.
The table Failover-Converting HA Source and non-HA Target to non-DR Systems gives an overview for converting
the DR system into two non-DR systems. The detailed steps are in "Procedure". If you are not placing the original
source system into operation, then only steps "1" through "6" in following Table need to be performed.

Table 112: Failover-Converting HA Source and non-HA Target to non-DR Systems
Step Original HA Source Active Original HA Source Standby Original Target System
Number System System
Stop Insight.
3 Run the convert script to change the

target system to standalone mode.
4 Run the database_failover.ksh script.
5 Run the restoreDatabasePasswords.sh

script.
6 Start Insight.
This is now a
standalone system that
replaces the DR
system.
Stop Insight.

the system to standalone mode.
Stop Insight.

the system to standalone mode.
13 Start Insight.
14 Start Insight.
Procedure
Use the following procedure to make the target system take over as a non-DR Insight server that replaces the

current DR system (failover).
In addition, perform Steps "10" through "" if you want to put the original HA source system into operation as an
additional non-DR system.
Table 113: Converting HA Source and non-HA Target to Non-DR Systems
Step System Action
1 Original Stop Insight on the original target system by executing the following command as user insight:
target
$ ./sonusEms stop
2 Original Unschedule DR monitoring on the original target system. As root, enter the following:
target

3 Original As root on the original target system, run the convert script to change the system to standalone mode:
target a. As root on the original target system, run the convert script as follows:
# ./convert

a) source
b) target
c) standalone
d) quit
Please select one of the options above (default:a)
[a|b|c|d]:
Answer c

Answer Y.
4 Original On the original target system, change to user oracle, and enter the following:
target
5 Original As root on the original target system, enter the following:

target
# ./restoreDatabasePasswords.sh

6 Original Start Insight on the original target system by logging in as insight and executing the following
target commands (this system starts up as a standalone EMS that replaces the DR system):
$ ./sonusEms start
If you do not have any IASs registered to the original source system, skip to Step "9".
8 Original On the original target system, enter the following commands to update the Insight IP address on the
target IASs that were registered to the original source system:
The Insight IP address on all IASs that were registered to the original source system are updated to the
IP address of the original target system.
9 If you are not putting the original source system back into service, this procedure is complete.
If the original source system is still serviceable and you want to put it into operation as an additional
non-DR system, continue to Step "10".
If you convert the original source system into an additional non-DR system and put it
into service, it should not be used to concurrently manage the same devices that the
original target manages.
10 Original Stop Insight on the original source standby system by executing the following command as user
source insight:
standby
$ ./sonusEms stop

11 Original Unschedule DR monitoring on the original source standby system. As root, enter the following:
source
standby
12 Original As root on the original source standby system, run the convert script to change the system to
source standalone mode:
standby a. As root on the original source standby system, run the convert script as follows:
# ./convert

a) source
b) target
c) standalone
d) quit
[a|b|c|d]:
Answer c.
Confirm that this system is currently an HA Standby

Answer Y.

Answer Y.

13 Original Stop Insight on the original source active system by executing the following command as user insight:
source
active Enter the following command:
$ ./sonusEms stop
14 Original Unschedule DR monitoring on the original source active system. As root, enter the following:
source
active

15 Original As root on the original source active system, run the convert script to change the system to
source standalone mode:
active a. As root on the original source active system, run the convert script as follows:
# ./convert

a) source
b) target
c) standalone
d) quit
[a|b|c|d]:
Answer c.
Confirm that this system is currently an HA Active

Answer Y.

Answer Y.
16 Original a. Remove the link "$ORACLE_BASE/orarepl"

source b. Copy the directory "orarepl" on raid to $ORACLE_BASE
active
17 Original a. Remove the link $ORACLE_BASE/orarepl.

source b. Copy the directory "orarepl" on original source active to $ORACLE_BASE
standby
For example:
scp -r oracle@<SOURCE_ACTIVE_IP>:$ORACLE_BASE/orarepl
$ORACLE_BASE

18 Original Start Insight on the original source active system by logging in as insight and executing the
source following commands.
active
$ ./sonusEms start
19 Original On the original source standby system as user insight, enter the following::
source
standby
$ ./sonusEms start
Failover-Converting DR System non-HA Source and HA Target to Separate non-DR Insight

Servers
Overview
DR system (failover). This scenario assumes that the current source is a non-HA system, the current target is an HA
The table Failover-Converting non-HA Source and HA Target to non-DR Systems gives an overview for converting
the DR system into two non-DR systems. If you are not placing the original source system into operation, then only
steps "1" through "10" in Failover-Converting non-HA Source and HA Target to non-DR Systems need to be
performed.
Table 114: Failover-Converting non-HA Source and HA Target to non-DR Systems
Step Original Source System Original HA Target Active System Original HA Target Standby System
Number
Stop Insight.

system to standalone mode.

Stop Insight.

7 Run the database_failover.ksh

script.
8 Run the
restoreDatabasePasswords.sh
script.
9 Start Insight.
This is now the HA

active system that
replaces the DR
system.
10 Start Insight.
This is now the standby

in the HA system that
replaces the DR
system.
window.)
Stop Insight.

change the system to
standalone mode.
14 Start Insight.
(End of maintenance
window.)
Procedure
Use the following procedure to make the HA target system take over as a non-DR HA system that replaces the

In addition, perform Steps "13" through "17" if you want to put the original source system into operation as an
Table 115: Converting non-HA source and HA Target to Non-DR Systems
Step System Action
1 Original Stop Insight on the original target standby system by executing the following command as user insight:
target
standby
$ ./sonusEms stop
2 Original Unschedule DR monitoring on the original target standby system. As root, enter the following:
target
standby

3 Original As root on the original target standby system, run the convert script to change the system to
target standalone mode:
standby a. As root on the original target standby system, run the convert script as follows:
# ./convert

a) source
b) target
c) standalone
d) quit
[a|b|c|d]:
Answer c

Answer Y.
4 Original Stop Insight on the original target active system by executing the following command as user insight:
target
active
$ ./sonusEms stop
5 Original Unschedule DR monitoring on the original target active system. As root, enter the following:
target
active

6 Original As root on the original target active system, run the convert script to change the system to standalone
target mode:
active a. As root on the original target active system, run the convert script as follows:
# ./convert

a) source
b) target
c) standalone
d) quit
[a|b|c|d]:
Answer c.

Answer Y.

Answer Y.
7 Original On the original target active system, change to user oracle, and enter the following:
target
active

8 Original As root on the original target active system, enter the following:
target
active
9 Original Start Insight on the original target active system by logging in as insight and executing the following
target commands (this system starts up as an HA active EMS that replaces the DR system):
active
$ ./sonusEms start
19 Original Start Insight on the original target standby system by logging in as insight and executing the following
source commands (this system starts up as the standby in the HA system that replaces the DR system).
standby
$ ./sonusEms start
11 f you have IASs registered to the original source system, continue to Step "12".
12 Original On the original target active system, enter the following commands to update the Insight IP address on
target the IASs that were registered to the original source system (use the well-known IP address for the HA
active system):
well-known IP address of the original HA target system.
13
If you are not putting the original source system back into service, this procedure is complete.

14 Original Stop Insight on the original source system by executing the following command as user insight:
source
$ ./sonusEms stop
15 Original Unschedule DR monitoring on the original source system. As root, enter the following:
source

16 Original As root on the original source system, run the convert script to change the system to standalone mode:
source
# ./convert

a) source
b) target
c) standalone
d) quit
[a|b|c|d]:
Answer c

Answer Y.
17 Original Start Insight on the original source system by logging in as insight and executing the following
source commands (this system starts up as a standalone EMS):
$ ./sonusEms start
Failover-Converting DR System HA Source and HA Target to Separate non-DR Insight

Servers
Overview

DR system (failover). This scenario assumes that the current source is an HA system, the current target is an HA
The table Failover-Converting DR System HA Source and HA Target to Separate non-DR Insight Servers gives an
overview for converting the DR system into two non-DR systems. The detailed steps are in "Procedure". If you are
not placing the original source system into operation, then only steps "1" through "10" in Failover-Converting DR
System HA Source and HA Target to Separate non-DR Insight Servers need to be performed.
Table 116: Failover-Converting DR System HA Source and HA Target to Separate non-DR Insight Servers
Step Original HA Source Original HA Source Original HA Target Active Original HA Target
Number Active System Standby System System Standby System
Prerequisites: Install/upgrade Insight V09.03.00 HA system and Prerequisites: Install/upgrade Insight V09.03.00 HA
start Insight system and start Insight
1 (Start of
maintenance
window.)
Stop Insight.
2 Unschedule DR
monitoring.

to change the target
standby system to
standalone mode.
window).
Stop Insight.

change the target active
7 Run the database_failover.ksh

script.
8 Run the
restoreDatabasePasswords.sh
script.

9 Start Insight.
This is now
the active in
the HA
system that
replaces the
DR system.
10 Start Insight.
(End of maintenance
window.)

standby in the HA
system that replaces
the DR system.
window).
Stop Insight.
12 Unschedule DR
Monitoring

change the source
standby system to
standalone mode.
window).
Stop Insight.
15 Unschedule DR
Monitoring

change the source active
system to standalone
mode.
17 Start Insight.
(End of maintenance
window.)
18
Start Insight.
(End of maintenance
window.)

Procedure
Use the following procedure to make the HA target system take over as a non-DR Insight server that replaces the
In addition, perform Steps "14" through "" if you want to put the original HA source system into operation as an
Table 117: Failover-Converting HA Source and HA Target to Non-DR Systems
Step System Action
1 Original Stop Insight on the original target standby system by executing the following command as user insight:
target
standby
$ ./sonusEms stop
2 Original Unschedule DR monitoring on the original target standby system. As root, enter the following:
target
standby

3 Original As root on the original target standby system, run the convert script to change the system to
target standalone mode:
standby a. As root on the original target standby system, run the convert script as follows:
# ./convert

a) source
b) target
c) standalone
d) quit
[a|b|c|d]:
Answer c


Answer Y.
4 Original Stop Insight on the original target active system by executing the following command as user insight:
target
active
$ ./sonusEms stop

5 Original Unschedule DR monitoring on the original target active system. As root, enter the following:
target
active
6 Original As root on the original target active system, run the convert script to change the system to standalone
target mode:
active a. As root on the original target active system, run the convert script as follows:
# ./convert

a) source
b) target
c) standalone
d) quit
[a|b|c|d]:
Answer c.

Answer Y.

Answer Y.

7 Original On the original target active system, change to user oracle, and enter the following:
target
active
8 Original As root on the original target active system, enter the following:
target
active
9 Original Start Insight on the original target active system by logging in as insight and executing the following
target commands (this system starts up as the active in the HA system that replaces the DR system):
active
$ ./sonusEms start
10 Original Start Insight on the original target standby system by logging in as insight and executing the following
target commands (this system starts up as the standby in the HA system that replaces the DR system):
standby
$ ./sonusEms start
12 Original On the original target active system, enter the following commands to update the Insight IP address on
target the IASs that were registered to the original source system:
active
The Insight IP address on all IASs that were registered to the original source system are updated to
the IP address of the original target system.

14 Original Stop Insight on the original source standby system by executing the following command as user
source insight:
standby
$ ./sonusEms stop
15 Original Unschedule DR monitoring on the original source standby system. As root, enter the following:
source
standby

16 Original As root on the original source standby system, run the convert script to change the
source system to standalone mode:
standby a. As root on the original source standby system, run the convert script as follows:
# ./convert

a) source
b) target
c) standalone
d) quit
[a|b|c|d]:
Answer c.

Answer Y.

Answer Y.

17 Original Stop insight on the original source active system, by executing the following command as user insight:
source
active
$ ./sonusEms stop
18 Original Unschedule DR monitoring on the original source active system.

source
active As root, enter the following:

19 Original As root on the original source active system, run the convert script to change the system to standalone
source mode:
active
# ./convert

a) source
b) target
c) standalone
d) quit
[a|b|c|d]:
Answer c.

Answer Y.

Answer Y.
20 Original Remove the link $ORACLE_BASE/orarepl.

source Copy the directory "orarepl" on raid to $ORACLE_BASE
active

21 Original Remove the link $ORACLE_BASE/orarepl.
source Copy the directory "orarepl" on original source active to $ORACLE_BASE
standby
For example:
scp -r $ORACLE_HOME/orarepl
oracle@<SOURCE_STANDBY_IP>:$ORACLE_HOME
22 Original Start Insight on the original source active system by logging in as insight and executing the following
source commands:
active
$ ./sonusEms start
23 Original Start Insight on the original source standby system by logging in as insight and executing the following
source commands:
standby
$ ./sonusEms start
Failover-Converting DR System non-HA Source and Target to Separate non-DR Insight

Servers
Overview
DR system (failover). This scenario assumes that the current source and target are non-HA systems and that DR is
set up and running on the source and target systems.
devices that the original target manages
The table "Failover-Converting DR System non-HA Source and Target to Separate non-DR Insight Servers " gives
an overview for converting the DR system into two non-DR systems. If you are not placing the original source
system into operation, then only steps "1" through "6" in "Failover-Converting DR System non-HA Source and
Target to Separate non-DR Insight Servers" need to be performed.

Table 118: Failover-Converting DR System non-HA Source and Target to Separate non-DR Insight Servers

Number
Stop Insight.
3 Run the convert script to change the system to standalone

mode.
4 Run the database_failover.ksh script.
5 Run the restoreDatabasePasswords.sh script.
6 Start Insight.
This is now a standalone system that

replaces the DR system.
Stop Insight.
9 Run the convert script to change the system to

standalone mode.
10 Start Insight.
Procedure
Use the following procedure to make the target system take over as a non-DR Insight server that replaces the
In addition, perform Steps "10" through "13" if you want to put the original source system into operation as an
Table 119: Switchover of the non-HA Source and HA Target
Step System Action

1 Original Stop Insight on the original target system by executing the following command as user insight:
target
$ ./sonusEms stop
2 Original Unschedule DR monitoring on the original target system. As root, enter the following:
target
3 Original As root on the original target system, run the convert script to change the system to source mode:
target
# ./convert

a) source
b) target
c) standalone
d) quit
[a|b|c|d]:
Answer c

Answer Y.

4 Original On the original target system, change to user oracle, and enter the following:
target
5 Original On the original target system, change to user root, and enter the following:
target
6 Original Start Insight on the original target system by logging in as insight and executing the following commands
target (this system starts up as a standalone EMS that replaces the DR system):
$ ./sonusEms start
8 Original On the original target system, enter the following commands to update the Insight IP address on the IASs
target that were registered to the original source system:
IP address of the original target system.
If you convert the original source system into an additional non-DR system and put it into
service, it should not be used to concurrently manage the same devices that the original
target manages.

10 Original Stop Insight on the original source system by executing the following command as user insight:
source
$ ./sonusEms stop
11 Original Unschedule DR monitoring on the original source system. As root, enter the following:
source

12 Original As root on the original source system, run the convert script to change the system to standalone mode:
source
# ./convert

a) source
b) target
c) standalone
d) quit
[a|b|c|d]:
Answer c

Answer Y.
13 Original Start Insight on the original source system by logging in as insight and executing the following commands
source (this system starts up as a standalone EMS):
$ ./sonusEms start
Stopping DR System Target Node for Maintenance
If the DR system target node is down for maintenance for an extended period of time, the source system will store
replication data on its own disk. This can result in the source’s disk becoming full. In addition, traps that state the
target is down will repeatedly be sent by the source. To avoid these issues, convert the source to standalone mode
if the target will be down for an extended period of time.
Stopping DR System Target Node for Maintenance

If the DR system target node is down for maintenance for an extended period of time, the source system will store
replication data on its own disk. This can result in the source’s disk becoming full. In addition, traps that state the
target is down will repeatedly be sent by the source. To avoid these issues, convert the source to standalone mode
if the target will be down for an extended period of time.
Account Management-DR Solaris


Idle Session Logout
next section.
values.
restrictions.
definact=90
Idle Session Logout
TMOUT=1800

TMOUT=1800
export TMOUT
Uninstalling Sonus Insight-DR Solaris


# cd /tmp
# ./emsUnInstall.sh

Disk Mirroring-DR Solaris

Disk Mirroring Overview-DR Solaris
Disk 1 Disk 3
Disk 2 Disk 4

mirrored disks

d10 d30 d100
d11 d31 d101
d13 d33 d103
d14 d34 d104
d15 d35 d105
d16 d36 d106
d20 d40 d200
d21 d41 d201

Enabling Disk Mirroring-DR Solaris
mirroring for Insight is supported on Netra T5220 four-disk systems.
Caution
# pkginfo SONSdmems

Ensure that the drive definitions are of format c1t*d*. If not, edit the /opt/SONSdmpsx/config/p
mirroring.

Enter yes.


Enter yes.

The
Enter yes.
the next step.

Enter yes.
# metastat -c

d106 m 2.0GB d16 d36 (resync-0%)
d105 m 50GB d15 d35 (resync-0%)
d15 s 50GB c1t0d0s5
d35 s 50GB c1t2d0s5
d104 m 59GB d14 d34 (resync-0%)
d14 s 59GB c1t0d0s4
d34 s 59GB c1t2d0s4
d103 m 4.0GB d13 d33 (resync-0%)
d100 m 5.0GB d10 d30 (resync-0%)
d101 m 15GB d11 d31 (resync-0%)
d11 s 15GB c1t0d0s1
d31 s 15GB c1t2d0s1

Enter yes.

Enter yes.

An
Enter yes.

the next step.

Enter yes.
# metastat -c
d200 m 76GB d20 d40 (resync-0%)

d20 s 76GB c1t1d0s0
d40 s 76GB c1t3d0s0
d106 m 2.0GB d16 d36 (resync-0%)
d105 m 50GB d15 d35 (resync-0%)
d15 s 50GB c1t0d0s5
d35 s 50GB c1t2d0s5
d104 m 59GB d14 d34 (resync-0%)
d14 s 59GB c1t0d0s4
d34 s 59GB c1t2d0s4
d201 m 60GB d21 d41 (resync-0%)
d21 s 60GB c1t1d0s1
d41 s 60GB c1t3d0s1
d103 m 4.0GB d13 d33 (resync-3%)
d100 m 5.0GB d10 d30 (resync-2%)
d101 m 15GB d11 d31 (resync-0%)
d11 s 15GB c1t0d0s1
d31 s 15GB c1t2d0s1
17. Enable disk mirror error reporting (through email). See Customizing Health Monitoring-DR Solaris.

18.
Health-DR Solaris.
# metastat -c
Checking the Status of Mirrors-DR Solaris
metastat -c
metadb -i
Disabling Disk Mirrors-DR Solaris
Caution


5.



# metastat -c
Suspending Disk Mirrors-DR Solaris
Resuming Disk Mirrors-DR Solaris

Detaching Slave Disk from the Mirror-DR Solaris
This procedure should be done on the EMS standalone server that is being upgraded.
In case of EMS HA setup, this procedure should be done on both servers of the EMS HA pair that are
getting upgraded.
$ metastat -c
d200 m 219GB d20 d40
d106 m 2.0GB d16 d36
d105 m 50GB d15 d35
d15 s 50GB c1t0d0s5
d35 s 50GB c1t2d0s5
d104 m 202GB d14 d34
d201 m 60GB d21 d41
d21 s 60GB c1t1d0s1
d41 s 60GB c1t3d0s1
d103 m 4.0GB d13 d33
d100 m 5.0GB d10 d30
d101 m 15GB d11 d31
d11 s 15GB c1t0d0s1
d31 s 15GB c1t2d0s1


this:
# metastat -c
d201 m 60GB d21
d21 s 60GB c1t1d0s1
d200 m 219GB d20
d106 m 2.0GB d16
d105 m 50GB d15
d15 s 50GB c1t0d0s5
d104 m 202GB d14
d103 m 4.0GB d13
d100 m 5.0GB d10
d101 m 15GB d11
d11 s 15GB c1t0d0s1
d41 s 60GB c1t3d0s1
d35 s 50GB c1t2d0s5
d31 s 15GB c1t2d0s1

Reattaching Slave Disk to the Mirror-DR Solaris

d201 m 60GB d21
d21 s 60GB c1t1d0s1
d200 m 219GB d20
d106 m 2.0GB d16
d105 m 50GB d15
d15 s 50GB c1t0d0s5
d104 m 202GB d14
d103 m 4.0GB d13
d100 m 5.0GB d10
d101 m 15GB d11
d11 s 15GB c1t0d0s1
d41 s 60GB c1t3d0s1
d35 s 50GB c1t2d0s5
d31 s 15GB c1t2d0s1


d200 m 219GB d20 d40

d106 m 2.0GB d16 d36
d105 m 50GB d15 d35
d15 s 50GB c1t0d0s5
d35 s 50GB c1t2d0s5
d104 m 202GB d14 d34
d201 m 60GB d21 d41
d21 s 60GB c1t1d0s1
d41 s 60GB c1t3d0s1
d103 m 4.0GB d13 d33
d100 m 5.0GB d10 d30
d101 m 15GB d11 d31
d11 s 15GB c1t0d0s1
d31 s 15GB c1t2d0s1
Replacing Disks-DR Solaris
disk:
# metadb


2.

# cfgadm -al
the failed disk.

8.
# metastat -c
d106 m 516MB d16 d26 (maint)

d105 m 109GB d15 d25 (maint)
d104 m 2.0GB d14 d24 (maint)
d103 m 3.0GB d13 d23 (maint)
d100 m 6.0GB d10 d20 (maint)
d11 s 15GB c1t0d0s1

Monitoring Disk Mirror Health-DR Solaris

dmchk.conf file (see "Customizing Health Monitoring-DR Solaris").
Customizing Health Monitoring-DR Solaris


Name
mirror status.


errors.

#
#
#
#smtp.host = plato

#
#
# Example:
#
#
#

#
#
#smtp.from = root

#
#
#smtp.timeout = 60

#
#
#smtp.debug = 0

# Possible values:
#
# default: 1
#send.mail = 1

#
#
Debug Logs-DR Solaris

Configuring Alternative Boot Device-DR Solaris

# init 0
ok printenv nvramrc

ok nvstore

ok boot
ok boot disk2
Customizing Disk Mirror Configuration-DR Solaris

# ---------------------------------------------------------------------
# ---------------------------------------------------------------------
svm.mirror.id = 1
# ---------------------------------------------------------------------
# ---------------------------------------------------------------------
svm.mirror.id = 2
Upgrading StorageTek Firmware for DR Setup
This section describes the procedure for upgrading StorageTek 2540 Array firmware upgrade using CAM Host
Management Software GUI. Insight V09.02.00 Release supports CAM Software version 6.7.0.12 and it suggests the
baseline firmware version for StorageTek 2540 Array is 07.35.55.11.
Insight V09.02.00 upgrade procedure is required to upgrade StorageTek Array firmware to the baseline firmware
version.
Prerequisites for upgrading StorageTek Firmware
In order to perform the upgrade effortlessly it is recommended to use the following supported browsers for
StorageTek Firmware upgrade with CAM 6.7 host management software.
Firefox 3.0
Microsoft Internet Explorer 6.0
Internet Explorer Versions 7 and 8 are not supported.
Enabling Remote Access to Oracle Java Web Console in Host Machine
Solaris OS 10 generally restricts port 6789 to listen to localhost only. This setting should be changed to enable
remote access to the Oracle Java Web Console and the Sun Storage Common Array Manager.

Perform the following steps in the Host Machine (controlling/using StorageTek Array) to enable console server to
respond to network requests.
1. Become superuser or assume an equivalent role on the system where the console is running.
2. Set a property to allow the console server to respond to network requests, refresh the service, and restart the
console server.
3. Execute the following commands:
# svccfg -s svc:/system/webconsole setprop options/tcp_listen=true

# svcadm refresh svc:/system/webconsole:console
# /usr/sbin/smcwebserver restart
StorageTek Array and Host Machine Information
Perform the following steps to acquire the StorageTek Array and Host Machine information.
1. The IP address of data Host machine (where the CAM software is installed and which can access the array
over the network/Ethernet). Also, note the IP address of StorageTek array controllers.
2. Login to the data host machine with root privilege and ensure that CAM CLI version is 6.7.0.12. Execute
below command.
# /opt/SUNWstkcam/bin/sscs --version
The following output is expected:
Sun Storage Common Array Manager v6.7.0.12
3. Log in to the /export/home/packages directory as a root user using the following command:
cd /export/home/packages
unzip 145965-03.zip
The 145965-03.zip file is also available from the Sonus Salesforce Customer Portal.
5. Change the directory to 145965-03.
cd 145965-03
6.

pkgadd -Gd . SUNWc2500
7. The following is displayed. Enter Y.
This package contains scripts which will be executed with super-user

permission during the process of installing this package.
Do you want to continue with the installation of <SUNWc2500> [y,n,?] y
8. After the installation complete, the following message is displayed.
Installation of <SUNWc2500> was successful.
StorageTek Firmware Upgrade
Perform the following procedure to upgrade the StorageTek Firmeware:
1. Open a web browser and point to the URL https://<IP_Address_of_the_DataHost>:6789. The

following screen is displayed.
2. Enter the root user credentials to login.
3. The following screen is displayed, after you login successfully.

4. Click the Sun Storage Common Array Manager link. The following screen is displayed.
5. Click the button to start the registration for the array. The following screen is displayed.

6. Select the option Enter IP address or hostname.
7. Enter the hostname or IP address of the RAID controller in IP Address. The user can also select the Scan the
local network option to discover the array.
8. Click the button. The following screen shows the progress of discovery process.
9. When progress is complete, click the button. The following screen is displayed.

10. Click the button to start the registration process. The following screen shows the progress of the
registration process.
11. When the registration is successful, The following screen is displayed.
12. Click the button. The following screen is displayed.

12.
13. Click the Storage System from the navigation panel on the left hand side of the screen.
14. Select the array using the checkbox and click the button. The following screen
is displayed.
15. Click the button to analyse the storage system firmware.

16. If the current firmware version is lower than baseline firmware proceed with the upgrade. The following
screen is displayed as an example.

17. Click the button to start the firmware upgrade process. The following screen is displayed.
18. Enter the valid password if the screen prompts and then click the button.
19. When the upgrade is complete, review the results and click the button to return to the main menu.
20. The Main Menu should contain the firmware version 07.35.55.11 for StorageTek Array.
ILOM Configuration on the Netra T5220 for DR Setup
Overview

Overview
Prerequisite
the SP interface.


of the
Parameter

system console.
system.
RUNNING state.
process.

power outage.
PROM card.
a.

2.

sc> logout
Ok> #.
"sc>"
sc> poweroff
sc> poweron
sc> console
>"
-> reset /SP
6. Enter y.

7. Press Enter.
Creating user...


Prerequisite

Requirements.

button.
set:
Verbosity: Normal
Level: Min
Update Mode: Normal
set:
Boot Timeout: 600
list.


2. Press Enter.
-> ls /SP/network
the SP Interface.
2. Press Enter.
-> cd /SP/network

7.

-> ls
Performing Post-installation or Upgrade Tasks on DR System
This section contains post-installation/post-upgrade tasks that you may need to perform.
For enabling licensing for devices in EMS, please refer to the “License Manager” section in the Insight User
Guide.
Task Purpose
Reattaching Slave Disk to the Mirror-HA For HA Solaris:

Solaris
If you have previously detached disk mirrors before upgrade, then Reattach
Or Disk Mirrors to re-establish the disk mirroring.
Enabling Disk Mirroring-HA Solaris Or
If you have never setup disk mirroring then enable disk mirroring.
Enabling Disk Mirroring For SA Solaris:
Perform this task to create new disk mirror so that data is in synch between
slave and master disks. The SalesForce upgrade overwrites the data on
disks 0 and 1. Hence, a new disk mirror must be created.
Setting IBM RAID Trap Destination Perform this task to set IBM RAID Trap destination.

SNMP Management Agent Configuration Perform this task if you are installing SNMP and need to configure the
SNMP Management Agent.
MPXIO from T5220 to IBM DS3524 Disk Activates multipathing from T5220 to IBM DS3524 Disk Arrays.
Arrays
Checking Database Software Shared Perform this task if you upgraded your Sonus application by using the Sonus
Memory Settings Salesforce Customer Portal.
Setting the Location of Core Dump Files Perform this task to set the core dump file location.
Synchronizing with the NTP Server Perform this task to synchronize with the NTP server.
Online Library Installation Perform this task to install the documentation.
Clearing Client Browser Cache After a Perform this task on the client after an Insight upgrade.
Software Upgrade
Netra T5220-Specific NVRAM Settings Perform this task to set the NVRAM variables to the correct values.
Enabling SSH Perform this task if you are using SSH for communication between the
Insight server and the PSX, SGX, and DSI.
Configuring TCP Wrappers-Aware Services Perform this task if you need to allow access to TCP Wrappers-aware
services such as SSH and NFS.
Enabling Hardware Traps Perform this task to enable the hardware traps.
SSL Certificate Installation Procedure Perform this task after an Insight installation if you need to support HTTPS
in a production environment.
Enabling Users to Create cron Jobs Perform this task if you need to allow users to create cron jobs.
Enabling Users to Create at Jobs Perform this task if you need to allow users to create at jobs.
Upgrades V07.01.01, V07.01.02, V07.02.01, V07.02.02, V07.02.03 and you want to
change any of the settings from the default of 4 weeks.
Licenses for Enabling Insight API, Insight Contact your Sonus representative to obtain software licenses.
CLI, SMS API, SGX API, Lawful Intercept
Provisioning API, and Traffic Manager
Configuring Multiple Network Interfaces Perform this task after an installation if the Insight server uses multiple
network interfaces.
Configure IP Network Multipathing for Perform this task for non-HA systems after an installation if the Insight
Standalone System server will be using IP network multipathing. This is recommended by Sonus
to protect the EMS from a single-switch failure.
Deploying LNP Adaptor Perform the task to deploy LNP Adaptor.
Enabling Mailx Perform this task to enable mailx.
Disabling unused EMS API versions Perform this task to save memory and avoid application failure.
Enabling/Disabling HTTP access on the Perform the task to enable and disable HTTP access on the EMS DR
EMS DR server server.
Forcing Network Interface Configuration Perform this task if you want to force network interface configuration using
Using Scripts-DR Setup scripts.
Configuring the Timezone on DR Solaris Perform this task to configure the Timezone.
Setting IBM RAID Trap destination for DR Setup

To receive IBM traps on Insight EMS, execute the following command:
For example:
MPXIO from T5220 to IBM DS3524 Disk Arrays for DR Setup

Multipath Input/Output (MPXIO) to IBM DS3524 helps array redundancy in affected deployments. MPXIO enables
fault tolerance to the array, such that applications on the host remains unaffected even if a single controller path
fails.
Activation of MPXIO connectivity to IBM Array is explained in the following procedure:
Prerequisites
Ensure that:
IBM Array product ID must be 1814.

The RAID is not mounted by executing the following command:
# df -h|grep raid
For an HA pair with the active system in service, the following steps has to be performed first on the standby node.
Perform the following procedure to activate multipathing from T5220 to IBM DS3524 Disk Arrays:
This procedure has to be followed only during maintenance period as it affects the systems service.
1. Check if MPXIO is enabled on the standby server by executing the following command:
# stmsboot -L
stmsboot: MPxIO is not enabled
2. Run the following command to enable multi-pathing to fiber channel devices with Solaris. This command also
updates /etc/vfstab for environments where IBM Array devices are mounted at boot time.

# stmsboot -D fp -eChecking mpxio status for driver fp
WARNING: This operation will require a reboot.
Do you want to continue ? [y/n] (default: y) y
The changes will come into effect after rebooting the system.
Reboot the system now ? [y/n] (default: y) y
updating /platform/sun4v/boot_archive
15 0 records in
15 0 records out
System reboots at this point, use console to reset or power cycle if the system hangs for more than 5
minutes.
Also, reboot when prompted. If the system stops in maintenance mode, login and run the following command
to force a second reboot.
init 6
3. Run the following command to validate if multi-pathing is enabled. All the multi-pathed devices gets listed.
# stmsboot -L
non-STMS device name STMS device name
------------------------------------------------------------------
The “STMS” device name is used exclusively for affected devices once multi-pathing is enabled.
4. Edit /export/home/ems/conf/HA/haConfiguration to reflect new block and raw device name, as

given by the stmsboot -L command.
That is, change the value of RaidBlockDeviceName to /dev/dsk/
c4t60080E50001C2FCE0000250F4FFFBE03d0s6
and RaidCharacterDeviceName to /dev/rdsk/ c4t60080E50001C2FCE0000250F4FFFBE03d0s6
(“s6” is added to the multi-path device name to match the original device's “s6” disk size)
5. Perform a manual Failover to convert the Active to Standby and perform steps 1-4 for new standby server.
For information on HA manual Failover, see "HA Manual Failover".
SNMP Management Agent Configuration for DR Setup


documentation.
configuration file:
authtrapenable 1
agentaddress <port>

6.
line would appear:
Continue to "Manually Starting and Stopping the SNMP Agent".
Checking Database Software Shared Memory Settings for DR Setup


# init 6
Setting the Location of Core Dump File for DR Setup

system.
dumpadm


Directory Name".



Synchronizing with the NTP Server-DR Solaris

Server IP address:
multicast 224.0.1.1
with

scvadm disable ntp
scvadm enable ntp
Online Library Installation or Updates-DR Setup

# ./docsInstall.sh
Clearing Client Browser Cache After a Software Upgrade-DR Solaris

displayed.

2. Select Java.

Netra T5220-Specific NVRAM Settings-DR Setup
eprom verbosity=min
Enabling SSH-DR Solaris

File Copy.
# cd /etc/ssh

2.

Change:
to
Change:
PermitRootLogin no
to
PermitRootLogin yes

5. Perform "Configuring TCP Wrappers-Aware Services".

Configuring TCP Wrappers-Aware Services-DR Solaris

and NFS.
/etc/hosts.allow
/etc/hosts.deny

sshd: LOCAL
to
sshd: ALL
ALL: ALL
to
#ALL: ALL
following command:
Enabling Hardware Traps-DR Solaris

# ./HwTrapGen.sh

Enabling Users to Create cron Jobs-DR Solaris

Enabling Users to Create at Jobs-DR Solaris

2.

Performance Data Retention Settings for Upgrades-DR Solaris

Intercept Provisioning API, and Traffic Manager-DR Solaris
The modules are:
Insight CLI
Insight API
Insight SMS API
Insight SGX API
Configuring Multiple Network Interfaces-DR Solaris

#
#
127.0.0.1 localhost

Configure IP Network Multipathing for Standalone System
Overview of IP Multipathing and the configure IPMP Script
Sonus recommends using IP Network Multipathing (IPMP) to provide non-HA systems with uninterrupted access to
a network when a network interface on the system fails or to protect the system from a single-switch failure. This is
achieved by creating a multipath group on the system, which consists of a primary and standby interface (Sonus
recommends that the primary interface and the standby interface be on different cards if possible). If a failure occurs
in the primary interface or its network adapter, the system automatically switches all the network access from the
failed interface and/or adapter to the standby interface.
The configureIPMP script will create an IP multipath group for you, based on the values you enter while running
the script.
Restrictions
You cannot run the configureIPMP script on High Availability (HA) systems. Multipath groups are set up on HA
systems when the configureHA script is run during HA configuration. For more information, refer Insight HA
Configuration.
Values You Provide
The configureIPMP script will prompt you for the following values. You can use the Table Information needed for
configureIPMP Script to record the values that you will enter when you run the script.
Primary interface — The physical interface that will handle the network access for the multipath group if the
Standby interface — The physical interface that will handle the network access for the multipath group if the
cards if possible.
IPMP group name — The name of the IP multipath group.
Test IP Address for Primary interface — A fully routable address that will be used exclusively for IPMP
Test IP Address for Standby interface — A fully routable address that will be used exclusively for IPMP
Data IP Addresses — The data IP addresses that will be supported by the multipath group. The data
Target IP Addresses — The IP addresses that will be the recipients of and responders to ICMP-echo
requests that are generated by the IPMP daemon. The target addresses are used to determine the state of a
physical interface in the multipath group, and must already exist on the same subnet as the data IP
addresses. You must enter a minimum of two and a maximum of five addresses. IPMP will ping the default
router if you enter less than five target addresses. If you do not want the default router to be pinged, enter five
target addresses.
Network number — The network number that applies to the test IP addresses, the data IP addresses, and
the target IP addresses.
Netmask — The netmask for the IP addresses.

Table 124: Information needed for configureIPMP Script
Standby interface for multipath group
Test IP address for primary interface
Test IP address for standby interface
Data IP addresses
Target IP addresses
Network number
Netmask
Exiting the Script
Creating an IP Multipath Group
Use the following procedure to create an IP multipath group. See "Values You Provide" for a description of the
values you will be entering.
1. On the Insight server, begin the IP multipath script:
# ./configureIPMP
2. Messages appear that give an overview of the script. When prompted, press Enter to continue.
3. Messages appear that explain the conventions used in the script. When prompted, press Enter to continue.
Enter the name of the primary interface, and press Enter.
5. The prompt Standby interface appears, followed by a list of interfaces.
Type the name of the standby interface, and press Enter.
IPMP group name: (Sonus-Mgmt)
Either accept the default value for the multipath group name by pressing Enter, or type a name and press
Enter.

7.
Test IP address for Primary interface
Type the test IP address for the primary interface, and press Enter.
Test IP address for Standby interface
Type the test IP address for the secondary interface, and press Enter.
9. A message appears that states you will enter a set of data addresses. When prompted, press Enter to
continue.
Data IP Address 1
Type the first data IP address that will be supported by the multipath group and press Enter.
Data IP Address 2
If desired, type the second data IP address that will be supported by the multipath group and press Enter. If
you do not want to enter a second address, press Enter.
If you entered a second data IP address, you will be prompted for a third IP address. You will continue to be
prompted for data IP addresses until you press Enter without typing an address.
12. A message appears that states you will enter a set of target IP addresses. When prompted, press Enter to
continue.
Target IP Address 1
Type the first target IP address that will be used by the multipath group and press Enter.
Target IP Address 2
If desired, type the second target IP address that will be used by the multipath group and press Enter. If you
do not want to enter a second address, press Enter.
If you typed a second target IP address, you will be prompted for another IP address. You will continue to be
prompted for target IP addresses until you press Enter without typing an address.

15.
Please provide a network number that applies to all of the addresses you have
The default value that is displayed will depend on the addresses you have entered so far. Either accept the
default network number for the addresses by pressing Enter, or type the network number and press Enter.
Please provide a netmask that applies to all of the addresses you have
Either accept the default value for the netmask of the addresses by pressing Enter, or type the netmask and
press Enter.
17. All the values that you have entered appear, followed by the prompt:
If the values are what you want, type y and press Enter. Continue to Step "18".
If the values are not what you want, type n and press Enter. Return to Step "4".
18. A message appears, stating that the exact changes that will be made will be displayed.
19. A message appears stating either that the network number and netmask combination has been added to
/etc/inet/netmasks, or that the information was already in the file.
20. A message appears showing either the changes that will be made to the hostname.<primaryinterface>
21. A message appears showing either the changes that will be made to the hostname.<standbyinterface>
22. Messages appear stating that the file /etc/init.d/ipmp.targets.sonus will be created, and that either unique
MAC addresses are already enabled on the system or they will be enabled.
This is followed by the prompt:
To make all the necessary file changes to create the multipath group, type y and press Enter. Continue to
Step "23".
If you do not want to create the multipath group, type n and press Enter. The script will exit. To run the script
again, return to Step "1".
23. Messages appear listing the files that are being created and stating that the changes are complete. This is
followed by the prompt:

Lastly, please reboot the system for the changes to take effect.
Reboot the system.
Changing the Addresses in a Multipath Group
If you want to change the IP addresses after you configure a multipath group, perform the following procedure.
1. On the Insight server, begin the IP multipath script with the -r option:
# ./configureIPMP -r
The original configuration that existed before you created the multipath group is restored (by restoring the
/etc/*.orig.sonus files).
2. Perform "Creating an IP Multipath Group". Enter the IP addresses that you want to use.
Deploying LNP Adaptor-DR Solaris


4.
Enabling Mailx-DR Solaris

Prerequisite



3.
pkgadd -d . all
Enabling Mailx
# vi /etc/hosts
#
#
:: 1localhost
127.0.0.1 localhost
cd /etc/mail/
# vi sendmail.cf



Disabling unused EMS API versions-DR Solaris

CAUTION

configuration.
Enabling and Disabling HTTP access on the EMS-DR Setup


2. To enable the access to HTTP, enter the following command:
# ./enableHTTP.sh

protocol to http
HTTP port 80
...........................................
............................................
Sonus Insight.
2. To disable the access to HTTP, enter the following command:

2.
# ./disableHTTP.sh

protocol to https
HTTPS port 443
Modifying /export/home/jboss/server/insight/deploy/
Done
Insight.
Enabling HTTP access on the EMS HA Server

The following section describes the procedure to enable HTTP access to the EMS HA server:

3. Enable the HTTP access on HA server - active. Execute the following command:
# ./enableHTTP.sh
4.

4. Enable the HTTP access on HA server - standby. Execute the following command:
# ./enableHTTP.sh

Disabling HTTP access on the EMS HA Server
Perform the following procedure to disable HTTP access to the EMS HA server:

3. Disable the HTTP access on HA server - active. Execute the following command:
# ./disableHTTP.sh
4. Disable the HTTP access on HA server - standby. Execute the following command:
# ./disableHTTP.sh

Enabling or Disabling HTTP access on the EMS DR server
Perform the following procedure to enable and disable HTTP access on the EMS DR server.
Enabling HTTP Access on DR

If the source is HA and the target is SA, execute the script for enabling HTTP for HA for the source system
(refer to "Enabling HTTP access on the EMS HA Server"), and execute the script for enabling HTTP for SA
on the target system (refer to "Enabling HTTP access on the EMS Standalone Server").
If both the source and target are HA, execute the script for enabling HTTP for HA on both the source and
target systems (refer to "Enabling HTTP access on the EMS HA Server").
If both the source and target are SA, execute the script of enabling HTTP for standalone on both the source
and target systems (refer to "Enabling HTTP access to the EMS Standalone server").
Disabling HTTP Access on DR

If the source is HA and the target is SA, execute the script for disabling HTTP for HA for the source system
(refer to "Disabling HTTP access on the EMS HA Server"), and execute the script for disabling HTTP for SA
on the target system (refer to "Disabling HTTP access on the EMS Standalone Server").
If both the source and target are HA, execute the script for disabling HTTP for HA on both the source and
target systems (refer to "Disabling HTTP access on the EMS HA Server").

If both the source and target are SA, execute the script for disabling HTTP for standalone on both the source
and target systems (refer to "Disabling HTTP access on the EMS Standalone Server").
Forcing Network Interface Configuration Using Scripts-DR Setup

Example

subsequent NIC.
Configuring the Timezone on DR Solaris

Example:
# TZ=US/Pacific
einfo.

Caution
LC_MESSAGES=C
# reboot
Migrating Insight Standalone 240 or 440 to a Netra 5220 for DR Setup
This section describes how to migrate an existing Standalone Insight EMS from a Netra 240 or 440 system to a
Netra T5220 system.
Insight User Guide.
This section includes the following"
Task Sequence for Migrating Standalone EMS to a Netra T5220 for DR Setup
Prerequisite
Passwords
Procedure
Task Sequence for Migrating Standalone EMS to a Netra T5220 for DR Setup
To migrate an existing Standalone Insight EMS from a Netra 240/440 server to a Netra T5220 server for DR setup,
perform the following tasks in the sequence given:
V09.02.00. Hence, kickstart the EMS Solaris system with 9.2.0 and migrate data to V09.02.00 Release with
T5220. After you have migrated the data, you can upgrade from V09.02.00 to V09.03.00 or V09.02.01 and
higher sustaining releases.

1. Kickstart Netra T5220 with EMS V09.02.00 Release. For more details about installing 9.2.0, refer the EMS
V09.02.00 Software Installation and Upgrade Guide.
2. Exporting Data from the Netra 240/440 Insight System (perform on the Netra 240/440 server)
3. Importing Data into the Netra T5220 System with EMS V09.02.00 Release (perform on the Netra T5220
server)
4. Upgrade T5220 System with EMS Software Release V09.02.00 to V09.02.01 or V09.03.00 Release
Export the data from your existing Insight Netra 240/440 system by performing the following procedure, which
generates three files. Later in this chapter you will need to import these files into the new Netra T5220 system.
1. Log on to the Netra 240/440 system as a user with root privileges.

where <yourbackupdirectory> should be replaced with the actual path for the directory in which you
wish to store your backup files. Use a directory that is external to the Insight machine. Use a directory name
that will clearly identify the EMS server that created the backup files. Make a note of the directory path
because you will need it later when migrating data back to the upgraded Insight system.
a. The script returns the following text:
The backup results in the creation of three files in the backup directory.
exp_data_manual.dmp
3. Continue to Importing Data into the Netra T5220.
Prerequisite
Before you import data into the Netra T5220, you must have installed Insight EMS V09.02.00. Restore of backup
must be performed on EMS Software Release V09.02.00.

Passwords
passwords.

– numbers
Procedure
Perform the following procedure to import the data that you earlier saved and exported from your Netra 240/440
system (see "Exporting Data from the Netra 240/440 Insight System"). The Netcool database is also imported.
1. Log on to the Netra T5220 system with EMS Release V09.02.00 as root.
From the backup directory you used for the existing Netra 240/440 EMS server in "Exporting Data from the
Netra 240/440 Insight System", copy the .dmp files to the /export/home/oracle/backup/dump
directory. Also, copy the backupFiles.tar file to the /tmp directory.
If the .dmp files are copied to /export/home/oracle/backup/dump using an unconventional method,
CAUTION
# ./emsMigrate.sh

###############################################################################
already
migrating

replaced
###############################################################################

Done
..............................................................................................
[y|Y,n|N] ?

*****************************************************************************
*****************************************************************************
#############################################################################################
oracle.
#############################################################################################
..............................................................................................
64bit Production
Done
Insight User Guide.

a. After migrating data from one EMS server (A) to another EMS server (B), and after registering Insight
node B, you need to unregister Insight node A (which will show up registered as a result of the
migration).
b. Associate the new Insight IP with the nodes. For information, see Associating the Nodes.
c. Disassociate the old Insight IP from the nodes. For information, see Disassociating the Nodes.
1. Login to Insight
a. SSH Port
b. Login (CLI)
c. Password (CLI)
5. Click on Update button and then click on Discover node.

b.

2.


e. Click OK.

Perform the following procedure to disassociate the node.
1. You need to disassociate the node.

Disassociate all of the nodes with the old EMS IP address to avoid traps being sent from the nodes to the old
EMS IP address
Figure 376: Disassociate IP Address Field
d. Click the Disassociate button.


Figure 377: Disassociate IP Address Confirmation Screen
e. Click OK.
V09.03.00 Release. For more information about upgrading, refer the section Upgrading Insight Standalone Using
Sonus Salesforce (Solaris).
Migrating Insight High Availability 240/440 to Netra T5220s for DR Setup
This section describes how to migrate an existing Insight High Availability system from Netra 240 or Netra 440
systems to Netra T5220 systems.
Insight User Guide.
V09.02.00. Hence, kickstart the Solaris box with 9.2.0 and migrate data to V09.02.00 Release with T5220.
After data is migrated to 9.2.0, you can upgrade from V09.02.00 to V09.03.00 or V09.02.01 and higher
sustaining releases.
Restrictions for Configuring HA

Hardware Setup of Netra 5220
Task Sequence for Migrating HA to Netra T5220s-DR Setup
Exporting Data from the HA System for DR
Setup and Configure Netra T5220 platforms with RAID Disk Arrays-DR Setup
Netra T5220 Disk Labeling and File System Creation for the RAID Disk Array-DR Setup
Private Network Setup for DR Deployment
Public Network Setup for DR Deployment
Importing Data into the Netra T5220s for DR Setup
The configure HA Script-DR Setup
Checking Interface Configuration and Routing Table for Netra T5220-DR Setup

Upgrading from V09.02.00 to V09.03.00 for DR Setup
Restrictions for Configuring HA

request.
Hardware Setup of Netra 5220

Task Sequence for Migrating HA to Netra T5220s-DR Setup

To migrate an existing Insight HA system from Netra 240/440 servers to Netra T5220 servers, perform the following
tasks in the sequence given:
1. Export the data from HA server (perform on the Netra 240/440 servers). For details, see Exporting Data from
the HA System for DR.
2. Kickstart EMS HA on Solaris Netra T5220 system with EMS Release V09.02.00. For more details, refer the
Insight EMS V09.02.00 Software Installation and Upgrade Guide.
data using EMS V09.02.00 Software Release. After data is restored on EMS V09.02.00, you can
upgrade from V09.02.00 to V09.03.00 Release.
3. Setup and configure RAID Disk Array with Netra 5220:

a. Setting up and configuring IBM DS3524 Storage System:
i. Netra T5220 Disk Labeling and File System Creation for the RAID Disk Array-DR Setup.
ii. IBM DS Storage Manager Software Installation-DR Setup.
iii. IBM DS3524 RAID Disk Array Configuration on Insight EMS Servers-DR Setup
b. Setting Up and Configuring Netra T5220 Systems with StorageTek 2540 Disk Array
Creation for the RAID Disk Array (perform on both the active and standby Netra T5220 servers).
5. Setup private network. See Private Network Setup for DR Deployment.
6. Setup public network. See Public Network Setup for DR Deployment.
7. Import the data back to the HA servers. For detailed procedure, see Importing Data into the Netra T5220s for
DR Setup (perform on both the active and standby Netra T5220 servers).
8. Run configureHA on both the active and standby Netra T5220 servers. See The configure HA Script-DR
Setup.
9. Verify interface and routing table on both the active and standby Netra T5220 servers. See Checking

9.
Interface Configuration and Routing Table for Netra T5220-DR Setup.

10. Upgrade from EMS Software Release V09.02.00 to V09.03.00. For more information on upgrade, refer
Upgrading from V09.02.00 to V09.03.00 Software Release .
Exporting Data from the HA System for DR

exp_data_manual.dmp
1. Log on to the Netra 240/440 active system (system A) as a user with root privileges.
4. Perform a failover from the Netra 240/440 active system (system A) to the Netra 240/440 standby system
(system B) as follows:

# ./hamgmt failOver
Setup and Configure Netra T5220 platforms with RAID Disk Arrays-DR Setup
Setting Up and Configuring Netra T5220 Systems with IBM DS3524 Storage System-DR
Setup
system.

Storage System:
Netra T5220 and IBM DS3524 Storage System Connections-DR Setup

IBM DS Storage Manager Software Installation-DR Setup
IBM DS3524 Storage Subsystem Controller IP Address Configuration-DR Setup
IBM DS3524 RAID Disk Array Configuration on Insight EMS Servers-DR Setup
Netra T5220 and IBM DS3524 Storage System Connections-DR Setup
T5220 systems.

IBM DS Storage Manager Software Installation-DR Setup


archive...
..
.....
......
....
.....
IBM DS3524 Storage Subsystem Controller IP Address Configuration-DR Setup
4Gbps, and 2Gbps
enclosures

servers.
2.

servers.
export DISPLAY
echo $DISPLAY
# ./SMclient
Management window.
discovery.
for the password.

12.

192.168.128.101 Port 1
192.168.129.101 Port 2
addresses.
IBM DS3524 RAID Disk Array Configuration on Insight EMS Servers-DR Setup

configuration.
For example,

Unnamed 10.54.58.94 10.54.58.95

For example,
EMSIBMRAID\";"
# SMcli -i -d
# SMcli -i -d
EMSIBMRAID 10.54.58.109 10.54.58.110


1. for 146GB
2. for 300GB

1. for 136GB
2. for 270GB

IP Address Configuration-DR Setup section when the following is prompted and press Enter.
For example, 10.54.58.109.

Enter.
SONSemsarray )
EMSIBMRAID
....
...
...
some time
#

12. Reboot EMS.
# reboot -- -r
Setting Up and Configuring Netra T5220 Systems with StorageTek 2540 Disk Array-DR
Setup
Array.

Netra T5220 and RAID Disk Array Connections-DR Setup

RAID Disk Array Controller IP Address Configuration-DR Setup
StorageTek 2540 RAID Disk Array Configuration on Insight EMS Servers-DR Setup
StorageTek Common Array Manager Software Installation-DR Setup
Netra T5220 and RAID Disk Array Connections-DR Setup
or nxge3.

RAID Disk Array Controller IP Address Configuration-DR Setup
controllers.

==============================
Q) Quit Menu
Enter Selection:
Enter 2.

7.
Enable IPv4 (Y/N)?
Enter Y.
Enter N.



Subnet Mask : 255.255.255.0

StorageTek 2540 RAID Disk Array Configuration on Insight EMS Servers-DR Setup



SONSemsarray.
StorageTek Common Array Manager Software Installation-DR Setup


Netra T5220 Disk Labeling and File System Creation for the RAID Disk
Array-DR Setup
Active System
1. Log on as root.
# format

ssd@w202500a0b85a427e,1f
ssd@w202400a0b85a427e,0
ssd@w202400a0b85a427e,1f



1060 cyl 53502 alt 2 hd 512 sec 64>

number):
Enter the number that corresponds to the disk c2t2d0 or c2t4d0.
are the same.

selecting c2t2d0
[disk formatted]
Enter yes.

/export/raid:

d.
total 16
lost+found
# df -h|grep raid
# df -h|grep raid
becomes active.
Standby System
system.


# format
ssd@w203400a0b867dc82,0
64>
ssd@w203400a0b867dc82,1f
ssd@w203300a0b867dc82,0
64>


64>

64>

1060 cyl 53502 alt 2 hd 512 sec 64>

number):
/export/raid:

total 16
# df -h|grep raid

# df -h| grep raid
becomes active.
Private Network Setup for DR Deployment

failure).
systems.
Procedure
systems.
5220 systems. The Table Private Network Interfaces and IP Addresses shows the recommended interfaces
across reboots) IP addresses to the private network interfaces you connected in Step 1. The Table Private
Network Interfaces and IP Addresses shows a sample IP address to use for each interface. Note that the first

2.
private network link is on a different subnet than the second private network link, as required.
b. Record the value of each IP address in System Information Worksheet; you will need these values
when running the configureHA script.
subnet mask in /etc/netmasks file as 192.168.5.0 255.255.255.0.


System Item Value

Public Network Setup for DR Deployment


Prerequisite
configureHA script.
System Item Value
Requirements
allowed.
Procedure
the primary and secondary interfaces are on different cards, as required. Record the values in System
Information Worksheet, you will need these values when running the configureHA script.
2. Log on as root.

3.

Record the value System Information Worksheet, you will need it when running the configureHA script.
Caution

System Item Value

Importing Data into the Netra T5220s for DR Setup

Use the following procedure to import the data that you earlier exported from your Netra 240/440 HA system. See
Exporting Data from the HA System for DR. The Netcool database is also imported.
Passwords
passwords.

lowercase letters
uppercase letters
numbers

special characters
Procedure
Perform the following procedure on both the active and standby Netra T5220 servers to import the data you earlier
exported from the Netra 240/440s:

in Step 2 of Exporting Data from the HA System for DR, copy the exp_data_manual.dmp and
exp_strct_manual.dmp files to the /export/home/oracle/backup/dump directory on the Netra
T5220. Also copy the backupFiles.tar file to the /tmp directory on the Netra T5220.
If the exp_data_manual.dmp and exp_strct_manual.dmp files are copied to
/export/home/oracle/backup/dump using an unconventional method, such as FTP, change the owner
and group of the files to Oracle and DBA.
CAUTION
# ./emsMigrate.sh

#######################################################################
You are going to migrate a previous EMS onto this system. Please
make sure you understand what you are doing. Before you proceed,
you should also have already run manualBackup.sh on the system you
want to migrate from, which generated backupFiles.tar, exp_data_manual.dmp,
and exp_strct_manual.dmp.

/export/home/oracle/backup/dump and specify the path for
backupFiles.tar at the following prompt.
All existing Insight-controlled passwords on this box will be wiped out

and replaced with the passwords from the restored data.
#######################################################################

Done
..............................................................................................
[y|Y,n|N] ?

*****************************************************************************
Tables.
*****************************************************************************
########################################################################################
oracle.
########################################################################################
..............................................................................................
64bit Production
Done
Insight User Guide.
The configure HA Script-DR Setup

for the first time.
Prerequisites
system information. Reachability Interface and IP Address table lists the information you will need, and the
procedures in which these values were assigned. You can enter your values into the table and use it as a reference
when you run configureHA.
Performed the first seven items in Task Sequence for Migrating HA to Netra T5220s-DR Setup
Behavior.


assigned

(Optional)

multipath group

multipath group

RAID device name Array-DR Setup
Standby First peer private IPv4/IPv6 address Private Network Setup for DR
Deployment
Primary interface for multipath group Public Network Setup for DR Deployment

multipath group

multipath group

(Optional)

RAID device name Array-DR Setup
Common Well-known (IPv4/IPv6/both) address Public Network Setup for DR Deployment

to both

Associating the Nodes-DR Setup



e. Click OK.
Configure HA on EMS systems-DR Setup
Configuring HA on Active System-DR Setup
Note


b.
$ sqlplus /nolog
SQL> startup
SQL> exit
in the section Netra T5220 Disk Labeling and File System Creation for the RAID Disk Array-DR Setup .
# ./configureHA

information.
q) quit


information.
q) quit
Note
OAM stands for Operations And Management. OAM IP address is used by the users to access all EMS
northbound interfaces like GUI, CLI, and API. A user can have two different networks for OAM and
signaling. In this scenario, EMS can act as a proxy for PSX to enable the PSX manager GUI to talk to
PSX. In a standalone EMS deployment with two different networks for OAM and signalling, the PSX
manager GUI connects to the EMS through the EMS OAM IP address, if PSX proxy mode is enabled. In
case of an EMS HA deployment with PSX proxy mode enabled and the user has two different networks
for OAM and signaling, the active EMS and standby EMS have their own respective OAM IP addresses.
In that case, the PSX manager GUI will use the appropriate OAM IP of the current active server.

Note
The OAM IP address is used by PSX to communicate with PSX GUI and EMS acts as a proxy for PSX.


information.
q) quit

functionality.
The
The
e1000g0
e1000g1
e1000g2
nxge0
nxge1

interface.

an option.

HA-PUB-GRP):


[y|n]:

10.54.5.32) : 10.54.5.32


10.54.5.34


Enter.



[y|n]:

Alives.
Alives
and press Enter.
You entered:



You entered...
User Name: "oracle"
Group Name: "dba"

for the RAID Disk Array-DR Setup and press Enter.
System Creation for the RAID Disk Array-DR Setup and press Enter.

(default:)...



system startup.

q) quit

created...default:
/export/home/oracle


Testing scp

(default: no) [y,n]

current hostname.

47. Perform the steps in Running the haMigrationFiles.sh for running the haMigrationFiles.sh file.
49. After you run the configureHA script on the active and standby systems, go to Performing Post-HA
Configuration Tasks-DR Setup.
Configure HA on Standby System-DR Setup
system, but both the Insight process and database instance should be stopped. Use the procedure detailed in
Configuring HA on Active System-HA Setup with the following differences:
In "step 1", ensure that the database instance is stopped.



Performing Post-HA Configuration Tasks-DR Setup
Step Tasks
Number
See Checking Interface Configuration and Routing Table for Netra T5220-DR Setup.
2. Enable Multipath for IBM RAIDS. For more details, see MPXIO from T5220 to IBM DS3524 Disk Arrays for
DR Setup.
Associate the new Insight IP with the nodes. For information, see Associating the Nodes-DR Setup.
Disassociate the old Insight IP from the nodes. For information, see Disassociating the Nodes-DR Setup.

1. Login to Insight
a. SSH Port
b. Login (CLI)
c. Password (CLI)
Disassociating the Nodes-DR Setup



d.
e. Click OK.
Checking Interface Configuration and Routing Table for Netra T5220-DR

Setup
Example Details

192.168.5.1.
Procedure
setup.
ifconfig -a

1
index 2
10.10.222.255
ether 0:14:4f:4f:c0:35
10.10.222.255
ether 0:14:4f:4f:c0:36
nxge0:1:
1500 index 29
10.10.222.255
ether 0:14:4f:4f:c0:37
10.10.222.255
ether 0:14:4f:42:64:8c
e1000g1:1:
1500 index 28
10.10.222.255
ether 0:14:4f:42:64:8e
netstat -rn

Routing Table: IPv4
----------------- -------------- ----- ----- ---- ----------
192.168.5.0 192.168.5.1 U 1 46522 nxge1
192.168.6.0 192.168.6.1 U 1 5585 e1000g2
10.10.222.0 10.10.222.30 U 1 284 e1000g1
10.10.222.0 10.10.222.37 U 1 23 nxge0
10.10.222.0 10.10.222.30 U 1 0 e1000g1:1
10.10.222.0 10.10.222.30 U 1 0 nxge0:1
224.0.0.0 10.10.222.31 U 1 0 e1000g0
default 10.10.222.1 UG 1 174989
127.0.0.1 127.0.0.1 UH 33100429493 lo0
Upgrading from V09.02.00 to V09.03.00 for DR Setup

V09.03.00 Release. For more information about upgrading, refer the section Upgrading Insight High Availability.
Migrating From Storage Tek RAID to IBM RAID on T5220-DR Setup
This section describes how to migrate from Storage Tek RAID to IBM RAID on Netra T5220.
If you are using a pre-9.0.0 EMS Solaris with StorageTEK RAID and want to migrate to IBM DS3524 RAID
then you must migrate using EMS V09.02.00 release. Direct migration from EMS pre-9.0.0 Release with
StorageTEK RAID to V09.03.00 Release with IBM DS3524 RAID is not supported. Jumpstart EMS Solaris
HA with IBM DS3524 RAID running on V09.02.00 and then perform migration. After you have migrated data
to V09.02.00 Release with IBM DS3524 RAID you can upgrade from V09.02.00 to V09.03.00 or V09.02.01
and higher sustaining releases.

When Migrating from EMS Migration Files generated are High-level migration Steps
Solaris StorageTEK RAID
Pre-9.0.0 Release backupFiles.tar 1. Jumpstart with EMS V09.02.00

exp_data_manual.dmp
DS3524 RAID.
exp_strct_manual.dmp 2. Import the migration files on EMS
V09.02.00 Release.
V09.03.00.
9.2.0 Release backupFiles.tar 1. Jumpstart with EMS V09.02.00

DS3524 RAID.
expdp_strct_manual.dmp 2. Import the migration files on EMS
V09.02.00 Release.
V09.03.00.
9.2.1 Release and above backupFiles.tar 1. Jumpstart with EMS V09.02.00

DS3524 RAID
expdp_stats_data_manual.dmp 2. Upgrade from V09.02.00 to V09.03.00
3. Import the migration files on EMS
expdp_strct_manual.dmp V09.03.00 Release.
Insight HA Configuration Restrictions

Hardware Requirements for Migration-DR Setup
High-level Tasks for Migrating From Storage Tek RAID to IBM RAID on T5220-DR Setup
Exporting Data-DR Setup
Setup and Configure Netra T5220 platforms with RAID Disk Arrays for Migration-DR Setup
Performing Netra T5220 Disk Labeling and File System Creation for the RAID Disk Array for
Migration-DR Setup
Private Network Deployment for Migration-DR Setup
Public Network Deployment for Migration-DR Setup
Importing Data into the Netra T5220s for Migration-DR Setup
Configuring High Availability on each Netra System for Migration-DR Setup
Checking Interface Configuration and Routing Table after Configuring HA-DR Setup
Upgrading from Insight EMS V09.02.00 to V09.03.00 Software Release-DR Setup
Insight HA Configuration Restrictions


request.
Hardware Requirements for Migration-DR Setup

High-level Tasks for Migrating From Storage Tek RAID to IBM RAID on
T5220-DR Setup
This section describes the procedure for migrating the Storage Tek RAID to IBM RAID on Netra T5220.

Table 133: Migrating from Storage TEK RAID to IBM RAID on T5220 for pre-9.0.0 or 9.2.0 Release
Step Task
Number
For detailed procedure, see Exporting Data-DR Setup.
data using EMS V09.02.00 Software Release. After data is restored on EMS V09.02.00, you
can upgrade from V09.02.00 to V09.03.00 Release.
T5220 platforms with RAID Disk Arrays for Migration-DR Setup.
4. Perform disk labeling and file creation for RAID Disk Array. See Performing Netra T5220 Disk Labeling and File
System Creation for the RAID Disk Array for Migration-DR Setup.
5. Setup private network. See Private Network Deployment for Migration-DR Setup.
6. Setup public network. See Public Network Deployment for Migration-DR Setup.
Migration-DR Setup.
8. Configure HA using same old T5220s with new IBM RAID. For detailed procedure, see Configuring High
Availability on each Netra System for Migration-DR Setup.
9. Verify interface and routing table. See Checking Interface Configuration and Routing Table after Configuring
HA-DR Setup.
g from Insight EMS V09.02.00 to V09.03.00 Software Release-DR Setup.
If you are migrating from 9.2.1 StorageTEK RAID to 9.3.0 release with IBM 3524 RAID, following will be the
high-level steps:

Table 134: Migrating from 9.2.1 Storage TEK RAID to 9.3.0 with IBM RAID
Step Task
Number
For detailed procedure, see Exporting Data-DR Setup.
data using EMS V09.02.00 Software Release. After data is restored on EMS V09.02.00, you
can upgrade from V09.02.00 to V09.03.00 Release.
T5220 platforms with RAID Disk Arrays for Migration-DR Setup.
4. Perform disk labeling and file creation for RAID Disk Array. See Performing Netra T5220 Disk Labeling and File
System Creation for the RAID Disk Array for Migration-DR Setup.
5. Setup private network. See Private Network Deployment for Migration-DR Setup.
6. Setup public network. See Public Network Deployment for Migration-DR Setup.
7. Configure HA using same old T5220s with new IBM RAID. For detailed procedure, see Configuring High
Availability on each Netra System for Migration-DR Setup.
8. Verify interface and routing table. See Checking Interface Configuration and Routing Table after Configuring
HA-DR Setup.
g from Insight EMS V09.02.00 to V09.03.00 Software Release-DR Setup .
Migration-DR Setup.
Exporting Data-DR Setup

Depending on the EMS Software Release from which you are exporting the data, the dmp file names would differ.

When Migrating from EMS Solaris StorageTEK RAID Migration Files generated are
exp_data_manual.dmp
1. Log on to the Netra 5220 active system (system A) connected to StorageTEK RAID as a user with root
privileges.
4. Perform a failover from the Netra 5220 active system (system A) to the Netra 5220 standby system (system
B) as follows:

b.
# ./hamgmt failOver
Setup and Configure Netra T5220 platforms with RAID Disk Arrays for
Migration-DR Setup
Migration-DR Setup
system.

The following are the high level/broader steps to setup and configure Netra T5220 Systems with IBM
DS3524 Storage System:
Netra T5220 and IBM DS3524 Storage System Connections for Migration-DR Setup
IBM DS Storage Manager Software Installation for Migration-DR Setup
IBM DS3524 Storage Subsystem Controller IP Address Configuration for Migration-DR Setup
IBM DS3524 RAID Disk Array Configuration on Insight EMS Servers for Migration-DR Setup
Netra T5220 and IBM DS3524 Storage System Connections for Migration-DR Setup
T5220 systems.

IBM DS Storage Manager Software Installation for Migration-DR Setup


archive...
..
.....
......
....
.....
IBM DS3524 Storage Subsystem Controller IP Address Configuration for Migration-DR

Setup

4Gbps, and 2Gbps
enclosures

servers.
servers.
export DISPLAY
echo $DISPLAY
# ./SMclient

Management window.
discovery.
for the password.
192.168.128.101 Port 1
192.168.129.101 Port 2
addresses.
IBM DS3524 RAID Disk Array Configuration on Insight EMS Servers for Migration-DR
Setup

configuration.

For example,

Unnamed 10.54.58.94 10.54.58.95

For example,
EMSIBMRAID\";"
# SMcli -i -d
# SMcli -i -d
EMSIBMRAID 10.54.58.109 10.54.58.110



1. for 146GB
2. for 300GB

1. for 136GB
2. for 270GB
IP Address Configuration for Migration-DR Setup section when the following is prompted and press Enter.
For example, 10.54.58.109.

Enter.

SONSemsarray )
EMSIBMRAID
....
...
...
some time
#

12. Reboot EMS.
# reboot -- -r
Performing Netra T5220 Disk Labeling and File System Creation for the RAID
Disk Array for Migration-DR Setup
Active System
1. Log on as root.
# format

ssd@w202500a0b85a427e,1f
ssd@w202400a0b85a427e,0
ssd@w202400a0b85a427e,1f


1060 cyl 53502 alt 2 hd 512 sec 64>

number):
selecting c2t2d0
[disk formatted]

Enter yes.

/export/raid:

total 16
lost+found
# df -h|grep raid
# df -h|grep raid
becomes active.
Standby System
system.


# format
ssd@w203400a0b867dc82,0
64>
ssd@w203400a0b867dc82,1f
ssd@w203300a0b867dc82,0
64>


64>

64>

1060 cyl 53502 alt 2 hd 512 sec 64>

number):
/export/raid:

total 16
# df -h|grep raid

# df -h| grep raid
becomes active.
Private Network Deployment for Migration-DR Setup

failure).
systems.
Procedure
systems.

2.
configureHA script.
c. In the /etc/netmasksfile, enter the network number and netmask for each of the private network
Example:


System Item Value

Public Network Deployment for Migration-DR Setup


Prerequisite
configureHA script.
System Item Value
Requirements
allowed.
Procedure
2. Log on as root.

3.

Caution

System Item Value
Importing Data into the Netra T5220s for Migration-DR Setup

Use the following procedure to import the data that you earlier exported from your Netra 5220 HA system connected
to StorageTEK RAID (see "Exporting Data-DR Setup"). The Netcool database is also imported.
Passwords
passwords.

lowercase letters
uppercase letters
numbers

special characters
Procedure
Perform the following procedure on both the active and standby Netra T5220 servers connected to IBM DS 3524
RAID to import the data you earlier exported from the Netra 5220 connected with StorageTEK RAID:

in Step "2" of "Exporting Data-DR Setup", copy the dmp files to the /export/home/oracle/backup/dump
directory on the Netra T5220. Also copy the backupFiles.tar file to the /tmp directory on the Netra
T5220.
If migrating from pre-9.2.0 then use the following dmp file names:
or
If migrating from 9.2.0 then use the following dmp file names:
CAUTION
# ./emsMigrate.sh

4.
#######################################################################
You are going to migrate a previous EMS onto this system. Please
make sure you understand what you are doing. Before you proceed,
you should also have already run manualBackup.sh on the system you
want to migrate from, which generated backupFiles.tar, exp_data_manual.dmp,
and exp_strct_manual.dmp.

/export/home/oracle/backup/dump and specify the path for
backupFiles.tar at the following prompt.
All existing Insight-controlled passwords on this box will be wiped out

and replaced with the passwords from the restored data.
#######################################################################

Done
..............................................................................................
[y|Y,n|N] ?

*****************************************************************************
Tables.
*****************************************************************************
########################################################################################
oracle.
########################################################################################
..............................................................................................
64bit Production
Done
Insight User Guide.
Configuring High Availability on each Netra System for Migration-DR Setup

for the first time.
Prerequisites
system information. The table System Information Worksheet lists the information you will need, and the procedures
in which these values were assigned. You can enter your values into the table and use it as a reference when you
run configureHA.
Performed the first five items in High-level Tasks for Migrating From Storage Tek RAID to IBM RAID on
T5220-DR Setup.
Reset the insight user password. See Changing the "insight" User Password and/or Password Expiration
Behavior . The active and standby systems must use the same insight user password.


assigned
Active First peer private IPv4/IPv6 address Private Network Deployment for
Migration-DR Setup

(Optional)

multipath group

multipath group

RAID device name Disk Array for Migration-DR Setup
Primary interface for multipath group Public Network Deployment for

Migration-DR Setup
multipath group

multipath group

(Optional)

RAID device name Disk Array for Migration-DR Setup
Common Well-known (IPv4/IPv6/both) address Public Network Deployment for

to both Migration-DR Setup

Configuring HA on EMS systems for Migration-DR Setup
Configuring HA on Active System for Migration-DR Setup

Configuring HA on Standby System for Migration-DR Setup
Performing Post-configure HA Tasks
Configuring HA on Active System for Migration-DR Setup

$ sqlplus /nolog
SQL> startup
SQL> exit
in the section Performing Netra T5220 Disk Labeling and File System Creation for the RAID Disk Array for
Migration-DR Setup.
4.

# ./configureHA


information.
q) quit

information.

q) quit
Type 2 and press Enter to enter the OAM IP addresses. In OAM IP configuration, the OAM IP address uses
PSX proxy mode.

PSX.



information.
q) quit

functionality.
The
The
e1000g0
e1000g1
e1000g2
nxge0
nxge1

interface.

15.
an option.

HA-PUB-GRP):


[y|n]:

10.54.5.32) : 10.54.5.32
The configureHA script provides the user to configure the HA in IPv4 or IPv6.

19.
Setup.

10.54.5.34


Enter.



24.

[y|n]:

Alives.
Alives
and press Enter.
You entered:




31.
You entered...
User Name: "oracle"
Group Name: "dba"

Enter the RAID’s mount point, which you established in Performing Netra T5220 Disk Labeling and File
System Creation for the RAID Disk Array for Migration-DR Setup and press Enter.
Enter the RAID’s device name, which you established in the section Performing Netra T5220 Disk Labeling
and File System Creation for the RAID Disk Array for Migration-DR Setup and press Enter.

(default:)...



system startup.

q) quit

created...default:
/export/home/oracle


Testing scp



(default: no) [y,n]
47.


current hostname.

50. Perform the steps in Running the haMigrationFiles.sh for running the haMigrationFiles.sh file.
52. After you run the configureHA script on active and standby systems, go to Starting and Stopping the Insight
Database.
Configuring HA on Standby System for Migration-DR Setup
Configuring HA on Active System for Migration" with the following differences:
In " step 1 ", ensure that the database instance is stopped.

In "this step ", when the script asks:


Performing Post-configure HA Tasks
After you run the configureHA scripts on both systems, perform the following tasks:
1. Verify that the interfaces and routing table are configured correctly. For more information, refer Checking
Interface Configuration and Routing Table for Netra 5220.
2. Enable Multipath for IBM RAIDs. For more details, refer MPXIO from T5220 to IBM DS3524 Disk Arrays for
DR Setup.
3. First start Insight on the active system and then on the standby system. For more information, see Starting
and Stopping the Insight Database.
4. Register or update the registration of each Insight device. For more information, refer the User Guide.
Checking Interface Configuration and Routing Table after Configuring HA-DR

Setup

Example Details

192.168.5.1.
Procedure
setup.
ifconfig -a

1
index 2
10.10.222.255
ether 0:14:4f:4f:c0:35
10.10.222.255
ether 0:14:4f:4f:c0:36
nxge0:1:
1500 index 29
10.10.222.255
ether 0:14:4f:4f:c0:37
10.10.222.255
ether 0:14:4f:42:64:8c
e1000g1:1:
1500 index 28
10.10.222.255
ether 0:14:4f:42:64:8e
netstat -rn

Routing Table: IPv4
----------------- -------------- ----- ----- ---- ----------
192.168.5.0 192.168.5.1 U 1 46522 nxge1
192.168.6.0 192.168.6.1 U 1 5585 e1000g2
10.10.222.0 10.10.222.30 U 1 284 e1000g1
10.10.222.0 10.10.222.37 U 1 23 nxge0
10.10.222.0 10.10.222.30 U 1 0 e1000g1:1
10.10.222.0 10.10.222.30 U 1 0 nxge0:1
224.0.0.0 10.10.222.31 U 1 0 e1000g0
default 10.10.222.1 UG 1 174989
127.0.0.1 127.0.0.1 UH 33100429493 lo0
Upgrading from Insight EMS V09.02.00 to V09.03.00 Software Release-DR

Setup
For more information about upgrading, refer the section Upgrading Insight EMS DR .
If you are migrating from pre-9.0.0 Release or from 9.2.0 release to 9.3.0 then you must first import the
migration files to 9.2.0 and then upgrade from 9.2.0 to 9.3.0.
If you are migrating from 9.2.1 release to 9.3.0 then you must first upgrade to 9.3.0 and then import the
migration files to 9.3.0 release.
Managing Security Settings of Insight DR on Solaris Platform


To enable, disable or for checking the current state of RPC processes on EMS Standalone Server, refer the
following sections:

Disabling RPC processes on EMS Standalone server
1. Change the directory to <BASEDIR>/conf/security directory by executing the following command:
starting the RPC
Starting rpcbind:
1. Change the directory to <BASEDIR>/conf/security directory by executing the following command:
Stopping the RPC
Stopping rpcbind:
1. Change the directory to <BASEDIR>/conf/security directory by executing the following command :

1.
To enable, disable or for checking the current state of RPC processes on EMS High Availability (HA) Active and
Standby System, refer the following sections:
Enabing RPC processes on EMS HA Server

Disabling RPC processes on EMS HA Server
Checking the current state of RPC processes on EMS HA Server
To enable RPC process on EMS server, execute the following steps on both active and standby systems:

both active and standby systems:
2. Enable the RPC processes, by executing the ./configureRPC.sh start command on both active and
standby systems:
starting the RPC
Starting rpcbind:
To disable RPC process on EMS server, execute the following steps on both active and standby systems:

2. Disable the RPC processes, by executing the ./configureRPC.sh stop command on active and
standby systems:

2.
Stopping the RPC
Stopping rpcbind:
To check for the status of RPC processes, execute the following steps on both active and standby systems:

2. Check the status of RPC processes, by executing the ./configureRPC.sh status command on active
and standby systems:
#cd <BASEDIR>/bin
starting the RPC
Starting rpcbind:

#cd <BASEDIR>/bin
Stopping the RPC
Stopping rpcbind:
#cd <BASEDIR>/bin

Installing and Upgrading Device Manager (DM)
Introduction
The upgradeDM.sh script helps with automatic installation of DM package across all involved EMS hosts (four
hosts if HA-DR, two hosts if HA or DR, one host if SA EMS). Use this script for either a first time installation of a DM
package on the EMS server, or for the upgrade of an already installed DM package to a newer version.
If an HA-DR setup, then you will be prompted twice for root password of DR target hosts, one prompt for each host.
Enter root password when prompted by the script.
This procedure involves EMS downtime, EMS server will not be available for the duration of the procedure.
DM upgrade script writes log messages to /var/sadm/install/logs/upgradeDM.log.
Prerequisites
The prerequisites for performing a Device Manager (DM) upgrade are as follows. Ensure that all the prerequisites
are completed, before performing a DM Upgrade.
1. SSH login should be enabled for root user to all involved EMS hosts.
2. EMS server on all hosts should be up and running.
3. If Solaris HA EMS, then HA actual/configured states should be either ACTIVE/ACTIVE or ACTIVE/STANDBY
or STANDBY/ACTIVE.
4. If a Solaris DR setup with HA-SA configuration with SA EMS being source, you would need to switchover first
to the HA site before running the DM upgrade script.
5. You can optionally manually download and place the DM package beforehand on all the involved EMS hosts.
This will speed up DM upgrade script execution somewhat as it does not need to transfer the tar.gz file (~
1GB for PSX) to all the involved hosts. See step 2 below for the directory where the tar.gz file needs to be
placed.
6. It is recommended that EMS server manual backup be performed before the start of this procedure.
Procedure
To upgrade a Device Manager (DM), execute the following steps:
1. Determine the host from where DM upgrade script is to be run:

If HA setup, choose primary host for Linux HA, or choose currently active host for Solaris HA.
If DR setup, choose the host (see rule above) on the source site.
2. Download the DM tar.gz to the host determined as mentioned above.
If Solaris EMS, put the tar.gz file under /export/home
If Linux EMS, put the tar.gz file under /opt/sonus
3. As root user, run the DM upgrade script on the host determined in step 1 above:
If the EMS system is Solaris, execute the following command:
# /export/home/ems/conf/upgradeDM.sh -f
/export/home/<dm-tar.gz-filename>
If the EMS system is Linux, execute the following command: :

# /opt/sonus/ems/conf/upgradeDM.sh -f /opt/sonus/<dm-tar.gz-filename>
For reference, refer the command output of executing the DM upgrade script for a Solaris HA
DR Setup.
Sample output:
===============
[emsnetra49 16:53:24] Detecting local EMS setup type... [Solaris HA DR]
This will install DM package EMS9.1.0-PSX9.1.2-DM1.0.0-solaris.pkg.tar.gz
on all involved Sonus Insight EMS hosts.
Do you want to continue? [y|n]: y
[emsnetra49 16:53:26] Performing DM upgrade on Solaris HA EMS DR setup
[emsnetra49 16:53:26] Preparing remote site 10.6.20.81
[emsnetra49 16:53:26] SSH should already be setup to HA peer 10.6.20.81
===============Command output cut for brevity====================
[emsnetra49 17:01:38] Successfully torn down SSH user-equivalence to

root@10.54.64.21
[emsnetra49 17:01:38] Performing final cleanup on remote site 10.6.20.81
[emsnetra49 17:01:39] SSH setup being maintained to HA standby 10.6.20.81
[emsnetra49 17:01:39] Performing final cleanup on localhost
[emsnetra49 17:01:39] Successfully completed DM installation steps on
Solaris HA EMS DR setup.

550-06484 EMS 9.3 Installation and Upgrade Guide PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

550-06484 EMS 9.3 Installation and Upgrade Guide PDF

Uploaded by

Copyright:

Available Formats

EMS 9.

3 Installation and Upgrade Guide

Element Management System

For the latest documentation, please visit https://support.sonus.net

Sonus Technical Publications Part Number: 550-06484

Copyright © 2015 Sonus Networks. All rights reserved. Page 1

documentation, please contact your Sonus customer support representative.

Disclaimer and Restrictions

Copyright © 2015 Sonus Networks. All rights reserved. Page 2

Compliance with Applicable Laws and Export Control Laws

access to it from territories where the content is illegal and prohibited.

252.227-7013 and FAR 52.227-19.

Copyright © 2015 Sonus Networks. All rights reserved. Page 3

Copyright © 2015 Sonus Networks. All rights reserved. Page 4

Introduction to Insight EMS

Searching Information in Online Documentation

EMS Server Based Documentation:

EMS SWe Documentation:

Copyright © 2015 Sonus Networks. All rights reserved. Page 5

Device Type Expansion Device Variants

GSX Gateway Server GSX 9000

Riverstone Riverstone Riverstone

SGX Signalling Gateway SGX 2000, SGX 4000

ASX Access Server ASX

DSI Data Stream Integrator DSI SWe

DSC Diameter Signalling Controller DSC, DSC SWe

BRX BGCF Routing Server BRX

PSX Policy Server PSX, PSX SWe

ADS Access Directory Server ADS

Figure 1: Sonus EMS

Copyright © 2015 Sonus Networks. All rights reserved. Page 6

Insight EMS Linux Installation and Upgrade

Insight EMS SWe Installation and Upgrade

Insight EMS Solaris Upgrade

Installing and Upgrading Device Manager (DM)

Copyright © 2015 Sonus Networks. All rights reserved. Page 7

Supported Hardware Platforms

Supported Hardware Platforms

EMS can be installed on server-based and virtualized environments.

EMS Deployment Configurations

EMS Standalone Deployment Configuration

EMS High-Availability (HA) Deployment Configuration

Copyright © 2015 Sonus Networks. All rights reserved. Page 8

EMS Standalone Deployment for DR Configuration

EMS HA Deployment for Disaster Recovery (DR) Configuration

EMS HA-Standalone Deployment for DR Configuration

Standalone An EMS Standalone system consisting of a single node.

Copyright © 2015 Sonus Networks. All rights reserved. Page 9

# grep "^_node01=`hostname`" /etc/rac.conf

Copyright © 2015 Sonus Networks. All rights reserved. Page 10

Hardware Requirements and Network Connectivity Information

Installing and Upgrading Standalone EMS on Linux

Installing and Upgrading EMS High Availability on Linux

Copyright © 2015 Sonus Networks. All rights reserved. Page 11

Installing and Upgrading Insight Application Server

Additional EMS Installation and Upgrade Procedures

Copyright © 2015 Sonus Networks. All rights reserved. Page 12

Common EMS Administrative Tasks

EMS Installation (Linux) Quick Reference

EMS Upgrade (Linux) Quick Reference

Copyright © 2015 Sonus Networks. All rights reserved. Page 13

Hardware Requirements and Network Connectivity Information

Hardware Cabling and Network Connectivity Information