how to test ema alarms

1.1.1 FDS Alarms

1.1.1.1 DB Interface

1.1.1.1.1 Oracle user or password error

Description: the purpose of this test case is to verify the event DB interface Oracle user or password error.

Prerequisite: The following prerequisite needs to be met prior to execution of this test case:

1) The OSS RC and EMA integration has been verified.

2) The Alarm DB interface Oracle user or password error has been defined in EMA system monitor GUI.

Procedure: Follow the steps as below:

Action: Login to EMA server 1 as user Sogadm and stop PL

sogadm> emaserver –domain PL stop

Result: PL stopped

Action: Edit /var/sog/data/database/FDS-PL.cfg and change the entry as below: sogadm> cd /var/sog/data/database

sogadm> cp –p /var/sog/data/database/FDS-PL.cfg \ /var/sog/data/database /FDS-PL.cfg.<yyyymmdd>

sogadm> vi FDS-PL.cfg <ProcLogDBLoginInfo> <DBUser type="Search">

<DBUserName>emalogsearcher_wrongUserName</DBUserName>

<DBUserPassword>#000223303030317063666……</DBUserPassword>

</DBUser>

<DBUser type="Operate">

<DBUserName>emalogoperator</DBUserName>

<DBUserPassword>#00022330303031706D72……</DBUserPassword>

</DBUser>

<DBConnectStr>emalog</DBConnectStr>

</ProcLogDBLoginInfo>

Note: Original value of “DBUserName” is emalogsearcher. <DBUserName>emalogsearcher</DBUserName>

ACTION: Restart PL and ProcLog cannot startup. The status of ProcessingLog is always "RECOVERING"

sogadm> emaserver –domain PL start

sogadm> emaserver –domain PL status

Result: The DBInterface:OracleUserPasswordError alarm received at OSSRC and in the system monitor

Post requisite: To recover ordinary operational status, tester needs to follow up the next steps. 1) Stop PL application using sogadm user. sogadm> emaserver -domain PL stop 2) Recover FDS.cfg to original file and check whether DBUserName is return to original value (emalogseacher). sogadm> cd /var/sog/data/database sogadm> cp –p FDS-PL.cfg.<yyyymmdd> /FDS-PL.cfg sogadm> view FDS-PL.cfg 3) Restart PL application and confirm whether ProcLog can startup properly. sogadm> emaserver -domain PL start sogadm> emaserver -domain PL status

1.1.1.1.2 Oracle connection string error

Description: The purpose of this test case is to verify the event DB interface oracle connection string error.

Prerequisite: The following prerequisites need to be met prior to execution of this test case.

1) OSS and EMA integration has been verified.

2) The alarm for DB interface oracle connection string error has been defined in system monitor GUI.

Procedure: Follow the procedure as below:

Action: Login to EMA server 1 as user Sogadm and stop PL


Result: PL stopped

Action: Edit /var/sog/data/database/FDS-PL.cfg and change the entry as

below: sogadm> cd /var/sog/data/database

sogadm> cp –p /var/sog/data/database/FDS-PL.cfg \ /var/sog/data/database /FDS-PL.cfg.<yyyymmdd>

sogadm> vi FDS-PL.cfg

<ProcLogDBLoginInfo>

<DBUser type="Search">

<DBUserName>emalogsearcher</DBUserName>

<DBUserPassword>#000223303030317063666……</DBUserPassword>

</DBUser>

<DBUser type="Operate">

<DBUserName>emalogoperator</DBUserName>

<DBUserPassword>#00022330303031706D72……</DBUserPassword>

</DBUser>

<DBConnectStr>emalog_worngConnectStr</DBConnectStr>

</ProcLogDBLoginInfo>

Note Original value of “DBConnectStr” is emalog. <DBConnectStr>emalog</DBConnectStr>

Action: Restart PL application and ProcLog cannot startup. The status of ProcessingLog is always "RECOVERING" sogadm> emaserver -domain PL start sogadm> emaserver -domain PL status

Result: The DBInterface:OracleConnectionStringError alarm received at OSSRC and in the system monitor

Post Requisite:To recover ordinary operational status, tester needs to follow up the next steps. 1) Stop PL application using sogadm user. sogadm> emaserver -domain PL stop 2) Recover FDS.cfg to original file and check whether DBConnectStr is return to original value (emalog). sogadm> cd /var/sog/data/database sogadm> cp –p FDS-PL.cfg.<yyyymmdd> FDS-PL.cfg sogadm> view FDS-PL.cfg 3) Restart PL application and confirm whether ProcLog can startup properly.

sogadm> emaserver -domain PL start sogadm> emaserver -domain PL status

1.1.1.1.3 Oracle server unavailable error

Description: The purpose of this test case is to verify the event oracle server unavailable error.


1) The OSSRC and EMA integration has been verified.

2) The Alarm DBInterface:OracleServerUnavailableError has been defined in EMA System monitor GUI.


Action: Log on EMA as emadba user and execute the following commands to login to sqlplus

tyEMA01:~ # su - emadba

emadba@tyEMA01:~> export ORACLE_SID=emadb

emadba@tyEMA01:~> sqlplus / as sysdba

Result: The following result is displayed, which indicates connected to sql plus

SQL*Plus: Release 11.2.0.3.0 Production on Tue Oct 30 15:45:54 2012

Copyright (c) 1982, 2011, Oracle. 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

SQL>

Action: Execute the below command to lock the EMALOGSEARCHER account

SQL> alter user EMALOGSEARCHER account lock;

Logon PN as sogadm user and restart ProcLog:

sogadm> emaps -k PROCLOG

Result: The DBInterface:OracleServerUnavailableError alarm received at OSSRC and in the system monitor

Post requisite: After raising alarm DBInterface:OracleServerUnavailableError, logon RN and unlock EMALOGSEARCHER account

# su – emadba

emadba@tyEMA01:~> export ORACLE_SID=emadb

emadba@tyEMA01:~> sqlplus / as sysdba

SQL> alter user EMALOGSEARCHER account unlock;

1.1.1.2 FDS Core

1.1.1.2.1 To verify Event Reciever connection

Description: The purpose of this test case is to verify thae alarms raised with the event Reciever connection. This test cases is under discussion.

1.1.1.3 MO Handler

1.1.1.3.1 Routing failed

Description: The purpose of this test case is to verify event MOHandler: RoutingFailed.


1) The OSSRC & EMA integration has been verified

2) The Alarm MOHandler:RoutingFailed has been defined in EMA System monitor GUI


Action: Login to PL admintool GUI from PN and select component Controller. Stop Procengine component in the processing via the GUI

Result: Procengine component stopped successfully.

Action: Prepare a temporary xml request

#su – sogadm

sogadm> echo '<Request MO="Sog.Cluster" Operation="Get"

SessionId=""></>' > /tmp/cluster.get.xml

Action: Send the request to procengine as a sogadm user

sogadm> xmlsend -domain PL /tmp/cluster.get.xml

Action: After seen the Alarm start the procengine component again and Check the status of EMA for all active and online

# su – sogadm


Result: The MOHandler:RoutingFailed alarm received at OSSRC and in the system monitor

1.1.1.3.2 Registration warning

Description: The MO name is already registered in the FDSServer process with the same address. This is a warning that a plug-in client has not properly unregistered its MO interface from the FDSServer process.



2) The Alarm MOHandler:RegistrationWarning has been defined in EMA System monitor GUI.


Logon to EMA as sogadm user and restart ProcLog:

sogadm> emaps -k PROCENGINE

Result: The MOHandler:RegistrationWarning alarm received at OSSRC and in the system monitor

1.1.1.3.3 Invalid registration

Description: The MO name is already registered in the FDSServer process with another address. It happens when two plug-ins try to use the same MO name. The plug-in that uses an existing MO name with another address fails to register and may not be created properly.

Prerequisite: The following prerequisites need to be met prior to execution of this test case:


2) The Alarm MOHandler:InvalidRegistration has been defined in EMA System monitor GUI.

Note: Make sure there's no NHFValidator on FDS-PL.cfg before this test case.

Procedure: Logon EMA as sogadm user and stop PL application.


Result: PL stopped.

Action: Edit the file /var/sog/data/database/FDS-PL.cfg. Add a new line in

<FDSMOHandler></FDSMOHandler> segment as below:

sogadm> cd /var/sog/data/database

sogadm> cp –p /var/sog/data/database/FDS-PL.cfg \

/var/sog/data/database /FDS-PL.cfg.<yyyymmdd>

sogadm> vi FDS-PL.cfg

<Subscriber MOName="NHFValidator" \

MOAddress="DefaultMO:NHFValidator/2.0"></Subscriber>

Action: Restart PL application

sogadm> emaserver -domain PL start

Action: Create Component NHFValidator by sogadm user.

sogadm> cd /var/sog/data/xml/component_requests/fast

sogadm> xmlsend -domain PL 2007_FSC-NHFValidation.xml

Result: The following error message will receive.

<?xml version='1.0' encoding='ISO-8859-1' standalone='no'?> <Response> <Error> <Code>2002</Code>

<Reason>Failed to create the following plugin: \ NHFValidator/1.0/A/1 \ Undo successful \ Failed to call initialize at level 2.\ Missing configuration</Reason> </Error> </Response>

The MOHandler:InvalidRegistration alarm received at OSSRC and in the system monitor

Post requisite: To recover ordinary operational status, tester needs to follow up the next steps.

1) Stop PL application using sogadm user.

sogadm> emaserver -domain PL stop

2) Recover FDS.cfg to original file and check there's no NHFValidator.


sogadm> cp –p FDS-PL.cfg.<yyyymmdd> FDS-PL.cfg

sogadm> view FDS-PL.cfg

3) Restart PL application and confirm whether ProcLog can startup properly.

sogadm> emaserver -domain PL start

sogadm> emaserver -domain PL status

1.1.1.3.4 Correct registration

Description: A successful registration of an MO in the MOHandler.

Prerequisite: The following prerequisites needs to be met prior to execution of this test case:

1) The OSSRC & EMA integration has been verified.

2) The Alarm MOHandler:CorrectRegistration has been defined in EMA System monitor GUI.

Procedure: Perform the steps as below:

Action: Telnet to EMA PN node as sogadm user and re-start the FDS server component

sogadm>emaps -k FDS-PL

Result: FDS-PL is killed

Action: Check that the all the plugin in the PL has become active

sogadm> emaserver status

Wait until all the plugins become active before go to the next test case.

Result: The MOHandler:CorrectRegistration alarm received at OSSRC and in the system monitor

1.1.1.3.5 Correct unregistration

Description: A successful Unregistration of an MO in the MOHandler. Purpose of this test case is whether OSS-RC can show the alarm slogan properly.



2) The Alarm MOHandler:CorrectUnRegistration has been defined in EMA System monitor GUI.

Procedure: Follow the below procedure:

Action: Check current ESA configuration (FDSAuthority:UserNotAllowed and FDSConfigurationManager:NotificationWarning) using the following command.

# /opt/sog/bin/alarmmapping –l

Revise the configuration to generate fake alarm

# /opt/sog/bin/alarmmapping –m

Please input alarmModule: FDSCore

Please input alarmErrorcode:505

The alarm has been existed, are you sure you want modify it?

(y/n):y

Please input alarmSeverity [6]: 6

Please input alarmModelDescription [FDSAuthority:UserNotAllowed]:

MOHandler:CorrectUnRegistration


MOHandler:CorrectUnRegistration

Please input ituAlarmEventType [10]: 10

Please input ituAlarmProbableCause [614]: 614

Note: After tester follow up above procedure, OSS-RC will detect “Cold restart” event (Warning) because it is updated about alarm configuration at EMA AS. Please ignore such event on OSS-RC.

Action: Generate the fake alarm by sogadm user using following procedure towards OSS-RC.

# su - sogadm

sogadm> telnet 0 3300

Enter command: LOGIN:sogadm:sog;

Enter command: LOGOUT;

Result: The MOHandler:CorrectUnRegistration alarm received at OSSRC and in the system monitor

Post requisite: After this test case finish, test engineer needs to return to original configuration as follows.





(y/n):y


Please input alarmModelDescription

[MOHandler:CorrectUnRegistration]:

FDSAuthority:UserNotAllowed

Please input alarmActiveDescription

[MOHandler:CorrectUnRegistration]:




Then, need to check configuration.


Then, need to check whether original alarm (FDSAuthority:UserNotAllowed) can see on OSS-RC

# su - sogadm




1.1.1.3.6 Invalid unregistration

Description: The MO name is already unregistered in the FDSServer process.



2) The Alarm MOHandler:InvalidUnRegistration has been defined in EMA System monitor GUI.

Procedure: Open admintool at PN as sogadm user and send a request like this (unregister one MO which actually doesn’t exist)

<Request MO=FDSController Operation= _-_UnregisterMO_-_ SessionId=>

<Name>abc</Name>

</>

Result: The MOHandler:InvalidUnRegistration alarm received at OSSRC and in the system monitor

1.1.1.4 FDS configuration manager

1.1.1.4.1 Write warning

Description: The FDS Configuration Manager fails to write its configuration to the local disk.



2) The Alarm FDSConfigurationManager:WriteWarning has been defined in EMA System monitor GUI.

Procedure: Follow the below procedure

1) Login to one EMA as sogadm user, Remove FDS-PL.cfg and create a folder having the same name


sogadm> mv FDS-PL.cfg FDS-PL.cfg.bak

sogadm> mkdir FDS-PL.cfg

2) Open admintool and modify the setting of CAI component, e.g., modifying

CAI IdleTimeout from 86400 to 300

Result: The FDSConfigurationManager:WriteWarning received at OSSRC and in the system monitor

Post requisite: To recover ordinary operational status, tester needs to follow up the next steps.

1) Remove FDS-PL.cfg


sogadm> rm -rf FDS-PL.cfg

2) Open admintool and modify the setting of CAI component, e.g., modifying

CAIIdleTimeout from 300 to 86400

In admintool, change the CAI Idle Timeout back to 300. A new FDS-PL.cfg will be created automatically.

1.1.1.4.2 Notification warning

Description: Cannot notify subscriber interface in the component.

Purpose of this test case is whether OSS-RC can show the alarm slogan properly.

Precondition: "FDSConfigurationManager:NotificationWarning" alarm is already defined on System Monitor GUI and the alarm is ceased before verification.


1) "FDSConfigurationManager:NotificationWarning" alarm is already defined on System Monitor GUI and the alarm is ceased before verification.

Procedure: Follow the below procedure

1) Log in to EMA AS (PN) as root user.

2) Check current ESA configuration (FDSAuthority:UserNotAllowed and FDSConfigurationManager:NotificationWarning) using the following command.


3) Revise the configuration to generate fake alarm





(y/n):y



FDSConfigurationManager:NotificationWarning


FDSConfigurationManager:NotificationWarning




4) Generate the fake alarm by sogadm user using following procedure toward OSS-RC.

# su - sogadm




Result: The FDSConfigurationManager:NotificationWarning received at OSSRC and in the system monitor






(y/n):y



[FDSConfigurationManager:NotificationWarning]:



[FDSConfigurationManager:NotificationWarning]:







# su - sogadm




1.1.1.5 FDS authority

1.1.1.5.1 Invalid session Id

Description: The purpose of this test case is to verify the alarm FDSAuthority: InvalidSessionId. This alarm is triggered when the session ID or user which has already logged in is expired due to tiume out

Prerequisite: None.


Action: Send the Login request to EMA

Result: User successfully logged in

Action: wait till the time out and send the provisioning request after the timeout

Result: The alarm is raised in the EMA for FDSAuthority Invalid session ID. Verify the alarm from the OSS.

1.1.1.5.2 User not allowed

Description: A user who has no authority tries to use a function in Ericsson Multi Activation

Prerequisite: The following prerequisite needs to be met prior toexecution of this test case:


2) The Alarm FDSAuthority:UserNotAllowed has been defined in EMA System monitor GUI.

Procedure: Follow the below procedure:

1) Open a terminal application program

2) Telnet to EMA PN node as sogadm user at CAI port 3300

3) In the Enter command prompt enter

Enter command: LOGIN:aaa:aaa;

4) After verified the alarm enter the below command to logout


Result: The FDSAuthority:UserNotAllowed received at OSSRC and in the system monitor

1.1.1.5.3 User logged in

Description: The purpose of this test case is to verify the alarm for the user who has the authority to use AS logs in to the system.



2) The Alarm FDSAuthority:UserLoggedIn has been defined in EMA System monitor GUI.


Open a terminal application program



Enter command: LOGIN:sogadm:sogadm;



Result: The FDSAuthority:UserLoggedIn has been verified in the system monitor GUI

1.1.1.5.4 User logged out

Description: The purpose of this test case is to verify the alarm for the user who has the authority to use AS logs out to the system.



2) The Alarm FDSAuthority:UserLoggedOut has been defined in EMA System monitor GUI.


Open a terminal application program



Enter command: LOGIN:sogadm:sogadm;



Result: The FDSAuthority:UserLoggedOut has been verified in the system monitor GUI

1.1.1.6 FDS Component Manager

1.1.1.6.1 Plugin Died

Description: The purpose of this test case is to verify the event FDScomponent manager plugin died. The PluginManager reports that the plug-in stated in the message is dead



2) The Alarm FDSComponentManager:PluginDied has been defined in EMA System monitor GUI.

Procedure: Follow the below steps:

1 Telnet to EMA PN node as sogadm user

2) As sogadm user re-start the CAI plugin

sogadm> emaps -k CAI

3) Check the OSSRC for the alarm message.

4) Check that the CAI plugin in the PL node has become active


Wait until CAI component become active before go to the next test case

Result: The FDSComponentManager:PluginDied received at OSSRC and in the system monitor

1.1.1.6.2 Plugin recovery failed

Description: The purpose of this test case is to verify event FDSComponentManager:PluginRecoveryFailed

Prerequisite: The following prerequisite needs t =o be met prior to execution of this test case:


2) The Alarm FDSComponentManager:PluginRecoveredFailed has been defined in EMA System monitor GUI.

Note: Make sure that No alarms are active or showing in the system monitor GUI. If any alarms presents please reset them before execute the below actions.

Procedure: Perform the below steps:

1) Telnet to EMA PN node as sogadm user

2) As sogadm user re-start PROCQUEUE components other than FDS-PL &

FDS-PM-PL eg: PROCQUEUE

sogadm> emaps -k PROCQUEUE

3) Now restart the FDS-PL plugin as sogadm user

sogadm> emaps -k FDS-PM-PL

Note you may experience a EMA PL restart due to this activity to create the alarm.


5) Re-start all the plugins by stop and re-start the EMA Processing Layer

this is due to restart the PROCQUEUE component which has been failed to

recover.


sogadm> emaserver –domain PL start

6) Check that all the plugins become active in the processing node

sogadm> emaseerver –domain PL status

7) If the plugin’s are not active wait until all plugin’s are active

Result: The FDSComponentManager:PluginRecoveredFailed alarm received at OSSRC and in the system monitor.

1.1.1.6.3 To verify event FDSComponentManager:InternalError

Description: The purpose of this test case is to verify the event FDSComponentManager:InternalError. This alarm is raised when there is some internal problem with the FDS component manager. It is very difficult to trigger this alarm manually.

1.1.1.6.4 Failed to save config

Description: The purpose of this test case is to verify event FDSComponentManager:FailedToSaveConfig


1) "FDSComponentManager:FailedToSaveConfig" alarm is already defined on System Monitor GUI and the alarm is ceased before verification.



2) Check current ESA configuration (FDSAuthority:UserNotAllowed and FDSComponentManager:FailedToSaveConfig) using the following command.

# /opt/sog/bin/alarmmapping -l






(y/n):y



FDSComponentManager:FailedToSaveConfig


FDSComponentManager:FailedToSaveConfig




4) Generate the fake alarm by sogadm user using following procedure toward

OSS-RC.

# su - sogadm




Result: The FDSComponentManager:FailedToSaveConfig received at OSSRC and in the system monitor






(y/n):y



[FDSComponentManager:FailedToSaveConfig]:



[FDSComponentManager:FailedToSaveConfig]:







# su - sogadm




1.1.1.6.5 Information

Description: The purpose of this test case is to verify FDS Component Manager: Information. This varies depending on the information contained within the alarm.



2) The Alarm FDSComponentManager:information has been defined in EMA System monitor GUI


1) Telnet to EMA node as sogadm user

2) As sogadm user re-start FDS-PL plugin

sogadm> emaps -k FDS-PL


4) Check that all the plugins become active in the processing node


5) If the plugin’s are not active then wait until all plugin’s are active

Result: The FDSComponentManager:information alarm received at OSSRC and in the system monitor.

1.1.1.6.6 Mo Request failed.

Description: the purpose of this test case is to verify the event FDSComponentManager:MORequestFailed. This happens when FDSController fails to process an MO request sent by the FDSComponentManager.

Prerequisite: The following prereauisite needs to be met prior to esecution of this test case:


2) The Alarm FDSComponentManager:MORequestFailed has been defined in EMA System monitor GUI


1) Log in to EMA as sogadm user and make sure CAI component is alive

sogadm> emaps


2) Open admintool and send the below request. This request is to start CAI. But, CAI

is already alive. So, this request will fail.

<Request MO="FDSController" Operation="Start" SessionId="">

<LogicalComponent>Cai/2.0/A/1</LogicalComponent>

</Request>

Result: The FDSComponentManager:MORequestFailed received at OSSRC and in the system monitor

Admintool show the following information.

1.1.1.6.7 MO request info

Description: The purpose of this test case is to verify To verify event FDSComponentManager:MORequestInfo. (MoRequest’s information: get, delete, set and etc.) The event is triggered when different configuration windows are opened in Ericsson Multi Activation GUI, for example, “Network Element” or “NE Cluster”.



2) The Alarm FDSComponentManager:MORequestinfo has been defined in EMA System monitor GUI.

Procedure: Perform the procedure as below:

1) Login to EMA PL admintool GUI at PN and select component configuration

2) Select CAI and Click "apply" button


Result: The FDSComponentManager:MORequestinfo alarm received at OSSRC and in the system monitor.

1.1.1.6.8 Rebuilding structures info

Description: The purpose of this test case is to verify event FDSComponentManager:RebuildingStructuresInfo. Component Manager is rebuilding internal structure of every component.

Prerequisite: The following prerequisite needs to be met prior to execution :


2) The Alarm FDSComponentManager:RebuildingStructuresInfo has been defined in EMA System monitor GUI


1) Telnet to EMA node as sogadm user

2) As sogadm user re-start the FDS server component

sogadm> emaps -k FDS-PL


4) Check that the all the plugin in the PL has become active


5) Wait until all the plugins become active before go to the next test case

Result: The FDSComponentManager:RebuildingStructuresinfo alarm received at OSSRC and in the system monitor.

1.1.1.7 Gui Driver

1.1.1.7.1 LicenceKeyerror

Description: The purpose of this test case is to verify the event GUIDRIVER:LicenceKeyError. We want to see that whether OSS-RC can show the alarm slogan properly. This event arises when there is an error in the Licence Key, either name or version is missing.


1) "GUIDriver:LicenceKeyError" alarm is already defined on System Monitor GUI and the alarm is ceased before verification.



2) Check current ESA configuration (FDSAuthority:UserNotAllowed and GUIDriver:LicenceKeyError) using the following command.



# /opt/sog/bin/alarmmapping -m




(y/n):y



GUIDriver:LicenceKeyError


GUIDriver:LicenceKeyError



Note After tester follow up above procedure, OSS-RC will detect "Cold restart" event (Warning) because it is updated about alarm configuration at EMA AS. Please ignore such event on OSS-RC.


OSS-RC.

# su - sogadm




Result: The GUIDriver:LicenceKeyError received at OSSRC and in the system monitor






(y/n):y



[GUIDriver:LicenceKeyError]: FDSAuthority:UserNotAllowed


[GUIDriver:LicenceKeyError]: FDSAuthority:UserNotAllowed






# su - sogadm




1.1.1.7.2 To verify event GUIDriver:CorbaConnectionFailure

Description: The purpose of this test case is to verify the event GUIDriver:CorbaConnectionFailure which triggered when the CORBA connection is not established. The alarm is not possible to trigger manually.

1.1.1.7.3 To verify event GUIDriver:LoadSubPluginOrComponentError

Description: The purpose of this test case is to verify the event GUIDriver:LoadSubPluginOrComponentError which is raised when there is some internal error in configuration which causes for the GUI Driver subplugin to load properly. It is not possible to trigger this alarm manually.

1.1.1.8 CAI driver

1.1.1.8.1 Server maximum connection reached

Description: The purpose of this test case is to verify event IfDriver:ServerMaxConnectionReached.

Prerequisite: The event IFDriver:ServerMaxConnectionReached defined in the system monitor gui


1) Open admintool GUI from EMA AS (PN) as sogadm user.

2) Select CAI parameter panel (Component configuration-> Cai), then, set

"NoOfConnections" value to "1".

Note Make a note about original value of the NoOfConnections.

3) Open terminal application at PN and Login to PN using port 3300

Telnet 0 3300 on PN.

# telnet 0 3300

Trying 0.0.0.0…

Connected to 0.

Escape character is '^]'.

CONNECTING TO CAI…

PROCESS cai3300 CONNECTED…

Enter command:

Result: The IfDriver:ServerMaxConnectionReached received at OSSRC and in the system monitor

1.1.1.8.2 Server Ready to accept

Description: The purpose of this test case is to verify the event IfDriver:ServerReadyToAccept


1) Precondition of this TC reuses another TC condition (Section 1.1.1.8.1).

Procedure: Follow the steps as below:

1) Following another TC (Section 1.1.1.8.1), reuse the terminal that is mentioned Step 3 of another TC , and wait until CAI session timeout or type "^]" to exist immediately

Enter command: ^]

telnet> quit

Connection to 0 closed.

Result: The IfDriver:ServerReadyToAccept received at OSSRC and in the system monitor

Post requisite:

1) Open admintool GUI from EMA AS (PN) as sogadm user.

2) Select CAI parameter panel (Component configuration-> Cai), then, set

"NoOfConnections" value to "original value".

The value refers to Step 2 on TC Section 1.1.1.8.1

1.1.1.8.3 Maximum retries to login exceeded

Description: The purpose of this test case is to verify the event IfDriver:MaxRetriesToLoginExceeded



2) The Alarm IfDriver:MaxRetrysToLogInExceeded has been defined in EMA System monitor GUI.

Procedure: Perform the procedures as below:

1) Open admintool GUI from EMA AS (PN) as sogadm user 2) Send a request using “Request Sender”

The request is (pay attention to the different newline symbols of UNIX and DOS. It’s better to type the request, not copying) <Request MO="FSCCai" Operation="Set" SessionId=""> <Configuration> <CaiServer> <ProtocolServers> <ProtocolServer Name="cai3300"> <CaiSessionConfig> <FirstMessage>CONNECTING TO CAI... PROCESS cai3300 CONNECTED... </FirstMessage> <CaiPrompt>"Enter command: "</CaiPrompt> <CaiConfirmation>CRNL</CaiConfirmation> <ShowEmptyArg>0</ShowEmptyArg> <CaiIdleTimeout>300</CaiIdleTimeout> </CaiSessionConfig> <CaiServerConfig> <Type>TCPIP</Type> <port>3300</port> <backlog>1</backlog> <NotAcceptMessage>Max number of connections exceeded.</NotAcceptMessage> </CaiServerConfig> <NoOfConnections>80</NoOfConnections> </ProtocolServer> </ProtocolServers> </CaiServer> </Configuration> </Request>

3) Wait several minutes. Then, open terminal application on PN and login to CAIDriver using port 3300 with incorrect password # telnet 0 3300 Trying 0.0.0.0… Connected to 0. Escape character is '^]'. CONNECTING TO CAI… PROCESS cai3300 CONNECTED… Enter command: LOGIN:sogadm:wrongPassword; RESP:3006; Connection to 0 closed by foreign host.

Result: IfDriver:MaxRetrysToLogInExceeded received at OSSRC and in the system monitor

Post Requisite: Do the following steps to restore CAIDriver configuration: 1) Open admintool GUI from EMA AS (PN) as sogadm user

2) Send a request using “Request Sender”. The request request is (pay attention to the different newline symbols of UNIX and DOS. It’s better to type the request, not copying) <Request MO="FSCCai" Operation="Set" SessionId=""> <Configuration> <CaiServer> <ProtocolServers> <ProtocolServer Name="cai3300"> <CaiSessionConfig> <FirstMessage>CONNECTING TO CAI... PROCESS cai3300 CONNECTED... </FirstMessage> <CaiPrompt>"Enter command: "</CaiPrompt> <CaiConfirmation>CRNL</CaiConfirmation> <ShowEmptyArg>0</ShowEmptyArg> <CaiIdleTimeout>300</CaiIdleTimeout> <CaiMaxLoginRetry>1</CaiMaxLoginRetry> </CaiSessionConfig> <CaiServerConfig> <Type>TCPIP</Type> <port>3300</port> <backlog>1</backlog> <NotAcceptMessage>Max number of connections exceeded.</NotAcceptMessage> </CaiServerConfig> <NoOfConnections>80</NoOfConnections> </ProtocolServer> </ProtocolServers> </CaiServer> </Configuration> </Request>

1.1.1.8.4 To verify event IFDriver:BadLinkDevice

Description: The purpose of this test case is to verify the event IfDriver:BadLinkDevice. The test case is not applicable.

1.1.1.9 Processing Engine

1.1.1.9.1 ConfigurationWriteFailure

Description: The purpose of this test case is to verify the event procengine:ConfigurationWriteFailure. This happens when the processing engine failed to write a configuration change in the configuration manager.


1) "ProcEngine:ConfigurationWriteFailure" alarm is already defined on System Monitor GUI and the alarm is ceased before verification.

Procedure: Perform the below procedure:


2) Check current ESA configuration (FDSAuthority:UserNotAllowed and

ProcEngine:ConfigurationWriteFailure) using the following command.







(y/n):y



ProcEngine:ConfigurationWriteFailure


ProcEngine:ConfigurationWriteFailure




4) Generate the fake alarm by sogadm user using following procedure towards OSS-RC.

# su - sogadm




Result: The ProcEngine:ConfigurationWriteFailure received at OSSRC and in the system monitor

Post Requisite: After this test case finish, test engineer needs to return to original configuration as follows.





(y/n):y



[ProcEngine:ConfigurationWriteFailure]:



[ProcEngine:ConfigurationWriteFailure]:







# su - sogadm




1.1.1.9.2 To verify event ProcEngine:BusinessLogicCompilationError

Description: The purpose of this test case is to verify the event ProcEngine:BusinessLoginCompilationError

Note: This alarm is raised when there is some business logic compilation error in the procengine, it is not possible to trigger this alarm manually.

1.1.1.9.3 Licence Key error

Description: The purpose of this test case is to verify event ProcEngine:LicenceKeyError. This condition comes when there is an error in the Licence Key, either name or version is missing.


1) "ProcEngine:LicenceKeyError" alarm is already defined on System Monitor GUI and the alarm is ceased before verification.



2) Check current ESA configuration (FDSAuthority:UserNotAllowed and

ProcEngine:LicenceKeyError) using the following command.







1.1.1.10 (y/n):y



ProcEngine:LicenceKeyError


ProcEngine:LicenceKeyError





OSS-RC.

# su - sogadm




Result: The ProcEngine:LicenceKeyError received at OSSRC and in the system monitor

Post Requisite: After this test case finish, test engineer needs to return to original configuration as follows.





(y/n):y



[ProcEngine:LicenceKeyError]: FDSAuthority:UserNotAllowed


[ProcEngine:LicenceKeyError]: FDSAuthority:UserNotAllowed






# su - sogadm




1.1.1.10.1 To verify event ProcEngine:UserNotAllowed

Description: The purpose of this test event ProcEngine:UserNotallowed


1) The connectivity between EMA and OSS RC is successfully verified.

2) The alarm ProcEngine:UserNotAllowed

Note: It is not possible to trigger this alarm manually.

1.1.1.10.2 To verify event ProcEngine:LoadSubPluginError

Description: The purpose of this test case is to verify the event ProcEngine:LoadSubPluginError



2) The alarm ProcEngine:LoadSubPluginError is already verified in EMA system monitor gui.


1.1.1.10.3 To verify event ProcEngine:LicenceExpiring

Description: The purpose of this test case is to verify the event ProcEngine:LicenceExpiring



2) The alarm ProcEngine:LicenceExpiring is already verified in EMA system monitor gui.


1.1.1.11 Processing Log

1.1.1.11.1 To verify event ProcLog:FileSystemError

Description: the purpose of this test case is to verify the event Proclog:FileSystem Error.


1.1.1.12 CAI3G session

1.1.1.12.1 To verify the event Over Limitation Of MaxNumOfCAI3GSession

Description: The purpose of this test case is to verify the event Over Limitation Of MaxNumOfCAI3GSession


1) The connectivity between EMA and OSS RC verified

2) The alarm for Over limitation of Max number of cai3G session already defined in EMA system monitor GUI

Procedure: Follow the procedure as below

Action: Open the CAI3G session control window to modify the max number of cai3G sessions click Administration > CAI3G Interface> Session Control. Change the value of max number of sessions to1 and save.

Result: The max value of cai 3g session saved

Action: send a login session reuest from SOAPUI to EMA.

Result: Login accepted and session established

Action: Send one more login request from another SOAP UI window.

Result: The Login rejected due to Over limitation of Max number of cai3G session and alarm sent to OSS verify the alarm.

Post requisite: Restore the max number of session to the original value in EMA GUI.

1.1.1.13 Mml Link Pool

1.1.1.13.1 MmlIP:linkFailure

Description: The purpose of this test case is to verify the event Mmllp:LinkFailure which arises when no connection can be established with a Network Element.

Prerequisite: The following prerequisite needs to be met prior to the execution of this test case:


2) The Alarm Mmllp:LinkFailure has been defined in EMA System monitor GUI

Procedure: Perform the procedure as below:

1) Using the EMA GUI at PN, open the system monitor alarm configuration window

2) Select a the Mmllp:LinkFailure Alarm definition

3) Configure the "Route on affected object" to ON (if it already defined use the NE already defined)

4) Using the EMA GUI, In the Network Element window Set an invalid IP address on selected MiO NE, eg: tyMiO01

5) Send some provisioning commands from CAS to Network Element for which the IP is changed in the above step.


8) Re-configure the NE back to the original IP address and send a provisioning request.

9) Check for the Mmllp:LinkRecovered Alarm at the OSSRC

10) Remove the "Route on affected object" selection, if its already there then leave it as it is.

Result: The Mmllp:LinkFailure alarm received at OSSRC and in the system monitor

1.1.1.13.2 Mmllp:LinkManangerConnectionFailure

Description: The purpose of this test case is to verify the event Mmllp:LinkManangerConnectionFailure.



2) The Alarm Mmllp:LinkManagerConnectionFailure has been defined in EMA System monitor GUI


1) Using the EMA GUI at PN, open the system monitor alarm configuration window

2) Select a the Mmllp:LinkFailure Alarm definition

3) Configure the "Route on affected object" to ON ( if it already defined use the NE already defined)

4) Using the EMA GUI, In the Network Element window Set an invalid IP address on selected MiO NE, eg: tyMiO01

5) Down LINKMANAGER component at both RNs as sogadm user

sogadm> emaps -k LINKMANAGER

6) Send some provisioning commands before the link manager comes up ( this step needs to be done very quickly)


2) Re-configure the NE back to the original IP address and send a provisioning command.

3) Remove the "Route on affected object" selection, if its already there then leave it as it is.

Result: The Mmllp:LinkManagerConnectionFailure received at OSSRC and in the system monitor

1.1.1.14 Logwriter

1.1.1.14.1 LogWriter:LoadFileStopped

Description: The purpose of this test case is to verify the event LogWriter:LoadFileStopped



2) The Alarm LogWriter:LoadFileStopped has been defined in EMA System monitor GUI


1) Open admintool GUI from EMA AS (PN) as sogadm user

2) Use "Component controller" to stop LogWriter.

Result: The LogWriter:LoadFileStopped received at OSSRC and in the system monitor

Post requisite: To restore LogWriter, use "Component controller" on admintool GUI to start LogWriter again.

1.1.1.14.2 LogWriter:FileLoadError

Description: The purpose of this test case is to verify the event LogWriter:FileLoadError

Prerequisite: The following prerequisite needs to be met prior to execution of this test case


2) The Alarm Failed to load Log file. has been defined in EMA System monitor GUI


1) Logon one PN and go to directory /opt/sog/bin. Revoke the execution permission of log_loader.sh

sogadm> cd /opt/sog/bin

sogadm> ls -al log*

sogadm> chmod a-x log_loader.sh

2) Go to directory /var/sog/logs/proclog/raw and create an empty file with the name CSO_2010-10-26_183156_90001.dat

sogadm> cd /var/sog/logs/proclog/raw

sogadm> touch CSO_2010-10-26_183156_90001.dat

3) It will take about 14 minutes to trigger this alarm. (Because LogWriter did retrying.)

Result: The LogWriter:FileLoadError received at OSSRC and in the system monitor


sogadm> cd /opt/sog/bin

sogadm> ls -al log*

sogadm> chmod 755 log_loader.sh

During the period of disabling log_loader.sh, there may also the normal provisioning log raw file is generated in /var/sog/logs/proclog/raw, e.g., CSO_2011-07-06_152303_296790001.dat. Wait several minutes until the correct log raw file, CSO_2011-07-06_152303_296790001.dat, disappears. Then check if there's a directory named recovery under /var/sog/logs/proclog/ and there's only CSO_2010-10-26_183156_90001.dat in that directory. If so, it doesn't matter and just delete it directly.

sogadm> cd /var/sog/logs/proclog/recovery

sogadm> cd 20110706

(this is an example, the actual directory name is the

same with the date when doing this test case)

sogadm> ls -al

CSO_2010-10-26_183156_90001.dat

cd /var/sog/logs/proclog/

sogadm> rm -rf recovery

1.1.1.15 Order scheduler

1.1.1.15.1 To verify Order Scheduler: QueueFull in Order Scheduler with alarmModule used in SNF as ‘‘OrderScheduler’’.

Description: The purpose of this test case is to verify the event Order Scheduler: QueueFull in Order Scheduler with alarmModule used in SNF as ‘‘OrderScheduler’’. This alarm is raised when the SOs in the Queue exceed 1000,000.


1) The connectivity between EMA and OSS RC successfully verified

2) The alarm Order Scheduler:Queue Full already defined in EMA.

3) Many SOS in Queue


Action: Stop the consumer of Sevice order scheduler by logging in to EMA GUI.

Result: Consumer stopped

Action: Keep sending multiple Async SOs until the total number of SOs exceed 1000,000

Result: The alarm Order Scheduler queue full sent to the OSS.

Post requisite: Start the consumer, all the SOs in the queue will start processing. Verify that all the SOs are successfully processed. If some of the SOs fail process them manually.

1.1.1.15.2 To verify Order Scheduler receiver Stopped - The Service Order Scheduler (SOS) receiver is stopped.

Description: The purpose of this test case is to verify the event which is sent to the OSS when the reciever is stopped


1) The connectivity between EMA and OSS RC is verified.

2) The alarm for event SOS receiver stopped is already defined in EMA.


Action1: Open the control menu in EMA GUI.

click Administration > Service Order Scheduler > Control.

Action2: The control panel is opened, click on stop tab in front of receiver

Result: receiver is stopped and alarm is sent to OSS. Verify the alarm at the OSS.

Post requisite: start the receiver by clicking start in control panel.

1.1.1.15.3 To verify OrderScheduler:ConsumerStopped - The SOS consumer is stopped.

Description: the purpose of this test case is to verify the alarm OrderScheduler:ConsumerStopped which is raised on the OSS when consumer is stopped.



2) The alarm for event SOS consumer stopped is already defined in EMA.


Action1: Open the control menu in EMA GUI.

click Administration > Service Order Scheduler > Control.

Action2: The control panel is opened, click on stop tab in front of consumer

Result: Consumer is stopped and alarm is sent to OSS. Verify the alarm at the OSS.

Post requisite: start the consumer by clicking start in control panel.

1.1.1.15.4 To verify Order Scheduler:CSO expired

Description: The purpose of this test case is to verify the event which is sent ot the OSS when the CSO is expired.

Prerquisite: The following prerequisite needs to be met prior to execution of this test case


2) The alarm Order schedulerCSO expired already defined in EMA

3) Many SOs in the order queue

Procedure : Follow the procedure as below

Action: Stop the consumer till many of the SO’s stored in queue are expired. And verify the alarm at the OSS

Result : The alarm OrderScheduler :CSO expired verified at the OSS

Post requisite: Start the consumer and execute the expired SOs manually.

1.1.1.16 EMC Storage

1.1.1.16.1 To verify EMC Storage :Information Trap - Information trap is from EMC storage

Description: The purpose of this test case is to verify the event EMC Storage :Information Trap - Information trap is from EMC storage

Prerequisite: the following prereauisite needs to be met prior to execution of this test case:

1) The connectivity between EMA and OSS RC verified successfully

2) The trap EMC Storage :Information Trap is already defined in EMA system monitor GUI

Procedure: This alarm is raise on the OSS in case of serious fault (internal error) in the EMC, this alarm is not possible to trigger manually.

1.1.1.16.2 To verify EMC Storage:Warning Trap - Warning trap is from EMC storage

Description: The purpose of this test case is to verify the event EMC Storage:Warning Trap



2) The trap EMC Storage:Warning Trap already defined in EMA system monitor GUI.

Procedure: This alarm is raise on the OSS in case of serious fault (internal error) in the EMC, this alarm is not possible to trigger manually.

1.1.1.16.3 To verify EMC Storage:Error Trap - Error trap is from EMC storage.

Description: The purpose of this test case is to verify the event EMC Storage:Error Trap



2) The trap EMC Storage:Error Trap already defined in EMA system monitor GUI.

Procedure: This alarm is raise on the OSS in case of serious fault (internal error) in the EMC, this alarm is not possible to trigger manually

1.1.1.16.4 To verify EMC Storage:Critical Trap - Critical trap is from EMC storage.

Description: The purpose of this test case is to verify the event EMC Storage:Critical Trap



2) The trap EMC Storage:Critical Trap already defined in EMA system monitor GUI.

Procedure: This alarm is raise on the OSS in case of serious fault (internal error) in the EMC, this alarm is not possible to trigger manually

1.1.2 Pacemaker Alarms

1.1.2.1 LVS External Resource VIP stopped

1.1.2.1.1 To verify LVS:ExternalVIPResourceStopped

Description: The Purpose of this test case is to verify the event LVS:ExternalVIPResourceStopped lvs-vip is used to set up VIP for incoming provisioning connections.


1) The connection between OSS- RC and EMA is verified

2) The alarm LVS:ExternalVIPResourceStopped configured in EMA system monitor GUI


Action: Login to EMA server 1 as user root

Result: user root logged in

Action: check the status of lvs –vip. (this should be running)

tyEMA01:~ # crm resource status lvs-vip

Result: The following is the expected result

resource lvs-vip is running on: tyEMA01

Action: stop the lvs – vip by executing the command

tyEMA01:~ # crm resource stop lvs-vip

Result: lvs – vip stopped and alarm raised on OSS. Verify the alarm on OSS

Post requisite:

1) start the lvs – vip by executing the command

tyEMA01:~ # crm resource start lvs-vip

3) Verify that it is started by executing the command

tyEMA01:~ # crm resource status lvs-vip

1.1.2.1.2 To verify lvs-ldirectordResourceStopped

Description: The Purpose of this test case is to verify the event LVS:LdirectordResourceStopped lvs-ldirectord is used to

activate ldirectord which configures and monitors IPVS.


1) The connection between OSS- RC and EMA is verified

2) The alarm LVS:LdirectordResourceStopped configured in EMA system monitor GUI

Procedure: Perform the steps as given below:



Action: check the status of lvs-ldirectord (this should be running)

tyEMA01:~ # crm resource status lvs-ldirectord

Result: The expected result is as shown below:

resource lvs-ldirectord is running on: tyEMA01

Action: stop the lvs-lDirectord by executing the command

tyEMA01:~ # crm resource stop lvs-ldirectord

Result: lvs-lDirectord stopped and alarm raised on OSS. Verify the alarm on OSS

Post requisite:

1) Start the lvs – ldirectord by executing the command

tyEMA01:~ # crm resource start lvs-ldirectord

3) Verify that it is started by executing the command

tyEMA01:~ # crm resource status lvs-ldirectord

1.1.2.1.3 To verify LVS: Internal VIP Resource Stopped

Description: The purpose of this test case is to verify the event LVS: Internal VIP Resource Stopped lvs-dip is used to setup VIP for distributing traffic to PN nodes in the AS scalable HA configuration. It is also used to forward outgoing requests from PN nodes. It is not used on the AS two nodes HA configuration

Prerequisite: The following prerequisite needs to be met prior to execution of this test case

1) The connection between EMA and OSS-RC verified

2) The alarm LVSInternal VIP resource stopped already defined in EMA system monitor GUI

Procedure: Perform the steps as below

Action: Login to server 1 as user root

Result: User root logged in

Action: Stop lvs-dip by executing the command

# crm resource stop lvs-dip

Result: LVS dip stopped, verify the alarm at OSS

Post requisite:

1) Start the lvs dip by executing the command

# crm resource start lvs-dip

2) Verify that the lvs dip is successfully started by executing the command

# crm resource status lvs-dip

1.1.2.1.4 To verify ExternalPingResourceonNode1Stopped

Description: The purpose of this test case is to verify ExternalPingResourceonNode1 stopped. This is basicall a clone set which runs on both server 1 and server 2 simultaneously, hence stopping this resource will stop it on both the servers and the alarms for both the servers will be raised on OSS RC.


1) The connection between EMA and OSS RC verified

2) The alarm ExternalPingResourceStopped already define in the EMA system monitor GUI



Result: User root logged in.

Action: Check the status of the resource ping external clone by executing the command

tyEMA01:~ # crm resource status ping-external-clone

Result: it will show that this resource is running on both the nodes.

resource ping-external-clone is running on: tyEMA01


Action: Stop the resource ping-external-clone by executing the command

tyEMA01:~ # crm resource stop ping-external-clone

Result: ping external clone stopped on both the nodes and the alarm raised on OSS, verify the alarm from OSS.

Post requisite:

1) Start the resource ping external clone by executing the command

tyEMA01:~ # crm resource start ping-external-clone

3) Verify that the resource is successfully started by executing the command

tyEMA01:~ # crm resource status ping-external-clone

Result: The command will show that the resource is started on both the ema nodes.



Note: It takes some time for the ping-external-clone to start up and stop, please wait for some time for the alarms to come and for the resource to start and stop.

1.1.2.1.5 To verify InternalPing Rersource on Node 1 Stopped

Description: The purpose of this test case is to verify InternalPingResource on Node1Stopped ping-internal is used to detect connectivity of the internal network. LVS, NFS and EMALOG services will refuse to start up if ping-internal fails to ping other nodes in the internal network.

Prerequisite:


2) The alarm InternalPingResource already defined on the EMA system monitor GUI

Procedure:


Result: User root Logged in

Action: Issue the below command to stop the resource ping-internal-clone

# crm resource stop ping-internal-clone

Result: The command above will stop the ping internal clone on node 1 and node 2 and the alarms will go to the OSS for this. Verify the alarms on the OSS

Post requisite:

1) Start the resource ping-internal-clone

# crm resource start ping-internal-clone

2) Verify that this resource is successfully started on both the nodes by issuing the command

#crm resource status ping-internal-clone

1.1.2.1.6 To verify ClusterMonitorResource on Node 1 stopped

Description: The purpose of this test case is to verify cluster-mon resource on node 1 is stopped. cluster-mon is used to monitor the status of Pacemaker resources. If any of these resources stops, SNMP notification will be sent out to the ESA server.

Prerequisite:


2) The alarm ClusterMonitorResource already defined in the system monitor gui

Procedure:



Action: Shut down Node 1 and verify the alarm from the second node and from the OSS

# init 0

Result: The resource base-clustermon-clone stopped on node 1 and the alarm sent to the OSS, verify the alarm for node 1 on the OSS

Post requisite:

1) Login to HPiLO of server 1 and power on the server

Open terminal with iLOM IP, ssh <ipaddress of hpilom server1>

2) Power on the server

</>hpiLO-> power on

1.1.2.1.7 To verify ClusterMonitorResourceonNode2 stopped

Description: : the purpose of this test case is to verify cluster-mon resource on node 2 is stopped. cluster-mon is used to monitor the status of Pacemaker resources. If any of these resources stops, SNMP notification will be sent out to the ESA server.

Prerequisite:


2) The alarm ClusterMonitorResource already defined in the system monitor gui

Procedure:



Action: Shut down Node 1 and verify the alarm from the second node and from the OSS

# init 0

Result: The resource base-clustermon-clone stopped on node 1 and the alarm sent to the OSS, verify the alarm for node 2 on the OSS

Post requisite:

1) Login to HPiLO of server 2 and power on the server

Open terminal with iLOM IP, ssh <ipaddress of hpilom server1>

2) Power on the server

</>hpiLO-> power on

1.1.2.1.8 To verify OracleDataGuardRoleMonitorResource on Node 1 stopped

Description: The purpose of this test case is to verify the event OracleDataGuardRoleMonitorResource dg-role is used to check the status data guard database. If data guard database is started and the role is primary, dg-vip will be started on the same node.

Prerequisite:


2) The alarm OracleDataGuardRoleMonitorResource already configured in the EMA system monitor GUI

Procedure:



Action: Stop the resource dg-role-clone

# crm resource stop dg-role-clone

Result: The resource dg-role-clone stopped on both the nodes and the alarms for both the nodes raised on the OSS. Verify the raised alarms on the OSS

Post requisite:

1) Start the resource dg-role-clone

# crm resource start dg-role-clone

2) Verify that the resource is successfully started

# crm resource status dg-role-clone

3) Logout from ema server

1.1.2.1.9 To verify OracleDataGuardObserverMonitorResource on Node1Stopped

Description: dg-observer is used to check the status data guard database and start data guard observer accordingly. If data guard database is started and the role is standby, the data guard observer will be started. In this test cases while execution we will also verify the alarm OracleDataGuardObserverMonitorResource on node 2 stopped.

Prerequisite:


2) The alarm OracleDataGuardObserverMonitorResource already defined in EMA system monitor GUI

Procedure:



Action: Stop the resource group dg-observer-clone by executing the command

# crm resource stop dg-observer-clone

Result: The resource grop stopped on both the nodes and alarms will be sent to the OSS, verify the alarms on the OSS

Post Requisite:

1) Start the resource group by executing the command

# crm resource start dg-observer-clone

2) Verify that the resource group is successfully started by executing the command

# crmresource status dg-observer-clone

1.1.2.1.10 To verify OracleDataGuardVIPResourceStopped

Description: dg-vip is used to set up VIP for accepting incoming requests to data guard database. The purpose of this test cases is to verify the raised alarm in case dg-vip is stopped

Prerequisite:

1) The connection between EMA and OSS RC verified

2) The alarm OracleDataGuardVIPResourceStopped already defined in the EMA system monitor gui

Procedure:



Action: stop the resource dg-vip

# crm resource stop dg-vip

Result: The resource dg-vip stopped and the alarm raised on the OSS. Verify the alarm on the OSS

Post requisite:

1) start the resource dg-vip

# crm resource start dg-vip


# crm resource status dg-vip

3) Logout from ema server

1.1.2.1.11 To verify OracleEMALOGInstanceResourceStopped

Description: The purpose of this test case is to verify OracleEMALOGInstanceResourceStopped

Prerequisite:


2) The alarm OracleEMALOGInstanceResourceStopped already defined in the EMA system monitor gui

Procedure:

Action: Login to ema server 1 as user root

Result: User root logged in\

Action: stop the resource emalog by issuing the command

# crm resource stop emalog-instance

Result: The resource emalog-instance stopped and alarm sent to the OSS. Verify the alarm on OSS

Post requisite:

1) Start the resource emalog-instance

# crm resource start emalog-instance

2) Verify that the resource emalog-instance is successfully started by executing the command

# crm resource status emalog-instance

1.1.2.1.12 To verify OracleEMALOGVIPResourceStopped

Description: The purpose of this test case is to verify the resource OracleEMALOGVIPResourceStopped

Prerequisite:


2) The alarm OracleEMALOGVIPResourceStopped already defined in the system monitor gui

Procedure:



Action: stop the resource emalog-vip

# crm resource stop emalog-vip

Result: The resource emalog-vip stopped and alarm sent to the OSS. Verify the alarm on the OSS

Post Requisite:

1) start the resource emalog-vip

# crm resource start emalog-vip

2) verify that the resource emalog-vip is successfully started by executing the command

# crm resource status emalog-vip

1.1.2.1.13 To verify NFSServerResourceStopped stopped

Description: The purpose of this test case is to verify the alarm for NFSServerResourceStopped.

Prerequisite:

1) The connectivity between EMA and OSS RC is verified

2) The Alarm NFSServerResourceStopped already defined in the EMA system monitor GUI

Procedure:



Action: Stop the resource nfs-server by executing the command

# crm resource stop nfs-server

Result: The nfs-server group stopped and the alarm sent on the OSS. Verify the alarm on the OSS

Post Requisite:

1) Start the nfs-server

# crm resource start nfs-server

2) Verify that the resource nfs-server is successfully started

# crm resource status nfs-server

1.1.2.1.14 To verify NFSVIPResourceStopped alarm

Description: the purpose of this test case is to verify the alarm for the event NFSVIPResourceStopped

Prerequisite:


2) The alarm NFSVIPResourceStopped successfully defined on the EMA system monitor GUI

Procedure:

Action: Login to ema server 1 as user root


Action: Stop the nfs-vip

# crm resource stop nfs-vip

Result: nfs-vip stopped and the alarm sent on OSS RC, verify the alarm on the OSS

Post requisite:

1) start the nfs-vip

# crm resource start nfs-vip

2) Verify that the nfs-vip is successfully started by executing the command

# crm resource status nfs-vip

1.1.2.1.15 To verify SplitBrainDetectorResourceStopped –

Description: the purpose of this test case is to verify the alarm when base-sbd resource is stopped. base-sbd is used to start Split Brain Detector which is responsible to kill nodes behaves abnormally.

Prerequisite:

1) The connectivity between OSS and EMA is verified

2) The alarm SplitBrainDetectorResourceStopped already defined on the EMA system monitor GUI

Procedure:

Action: Login to EMA serevr 1 as user root


Action: stop the resource base-sbd

# crm resource stop base-sbd

Result: The resource base-sbd successfully stopped and the alarm sent on the OSS. Verify the alarm on the OSS

Post requisite:

1) start the resource base-sbd

# crm resource start base-sbd

2) Verify that the resource base-sbd is successfully started

# crm resource status base-sbd

1.1.2.1.16 To verify OrchestratorFileSystemResourceStopped

Description: The purpose of this test case is to verify the event OrchestratorFileSystemResourceStopped fs-orchestrator is used to mount the device /dev/global/orchestrator.

Prerequisite:


2) The alarm OrchestratorFileSystemResourceStopped already defined on the EMA system monitor GUI

Procedure:



Action: Stop the fs-orchestrator for verifying the alarm

# crm resource stop fs-orchestrator

Result: fs-orchestrator stopped and the alarm sent to the OSS, verify the alarm on the OSS

Post requisite:

1) start the fs-orchestrator

# crm resource start fs-orchestrator

2) Verify that the resource fs-orchestrator is successfully started by executing the command

# crm resource status fs-orchestrator

1.1.2.1.17 To verify NfsinfoFileSystemResourceStopped

Description: The purpose of this test case is to verify the alarm raised on the OSS when fs-nfsinfo resource is stopped. fs-nfsinfo is used to mount the device /dev/global/nfsinfo.

Prerequisite:


2) The alarm NfsinfoFileSystemResourceStopped is already defined on the EMA system monitor GUI.

Procedure:



Action: Stop the resource fs-nfsinfo to verify its alarm on the OSS

# crm resource stop fs-nfsinfo

Result: The resource fs-nfsinfo successfully stopped and the alarm sent on the OSS. Verify the alarm on the OSS

Post requisite:

1) start the resource fs-nfsinfo

# crm resource start fs-nfsinfo


# crm resource status fs-nfsinfo

1.1.2.1.18 To verify the event BackupFileSystemResourceStopped

Description: The purpose of this test case is to verify the alarm BackupFileSystemResourceStopped this alarm is raised and sent to the OSS when fs-backup resource is stopped. fs-backup is used to mount the device /dev/global/backup

Prerequisite:


2) The alarm BackupFileSystemResourceStopped already defined on the EMA system monitor GUI

Procedure:



Action: Stop the resource fs-backup for the verification of its alarm on the OSS

# crm resource stop fs-backup

Result: The resource fs-backup stopped and the alarm sent on the OSS, verify the alarm on the OSS

Post Requisite:

1) Start the resource fs-backup

# crm resource start fs-backup

2) Verify that the resource fs-backup successfully started by executing the command

# crm resource status fs-backup

1.1.2.1.19 To verify AgentdataFileSystemResourceStopped

Description: The purpose of this test case is to verify AgentdataFileSystemResourceStopped This alarm is raised when fs-agentdata resource is stopped. fs-orchestrator is used to mount the device /dev/oracle/agentdata.

Prerequisite:


2) The alarm AgentdataFileSystemResourceStopped already defined in the EMA system monitor GUI

Procedure:



Action: stop the resource fs-agentdata

# crm resource stop fs-agentdata

Result: The resource fs-agentdata stopped and alarm sent to the OSS, verify the alarm from the OSS

Post Requisites:

1) start the resource fs-agentdata

# crm resource start fs-agentdata


# crm resource status fs-agentdata

1.1.2.1.20 To verify the event EmalogFileSystemResourceStopped

Description: The Purpose of this test case is to verify the alarm for EmalogFileSystemResourceStopped.

Prerequisite:


2) The alarm EmalogFileSystemResourceStopped already defined in the EMA system monitor GUI

Procedure:

Action: login to EMA server 1 as user root


Action: stop the resource fs-emalog to verify its alarm

Result: the resource fs-emalog successfully stopped and the alarm raised on the OSS. Verify tha alrm on the oss

Post requisite:

1) start the resource fs-emalog

# crm resource start fs-emalog


# crm resource status fs-emalog

1.1.2.2 Data Guard Alarms

1.1.2.2.1 To verify DataGuard:NoListenerError.

Description: The purpose of this test cases is to verify the alarm DataGuard:NoListenerError which is raised when no listener is running on the oracle server

Prerequisite:


2) The alarm DataGuard:NoListenerError already configured in EMA system monitor GUI

Procedure:

Action: Login to server 1 as user emadba and issue the below command to stop the listener

# su - emadba

tyEMA01$ lsnrctl stop

Result: The following alarm is raised on the OSS DBInterface:OracleServerUnavailableError

Action: wait for approximately 3-4 minutes and the following alarm will be triggered on the OSS

DataGuard:NoListenerError.

Result: The alarm that the dataguard no listener is running is displayed and verified from the OSS.

Post requisite:

1) Login to server 1 by user emadba issue the below command to start the listener.

# su – emadba

tyEMA01$ lsnrctl start

1.1.2.2.2 To verify NoemadbInstanceError

Description: The purpose of this test case is to verify the alarm Noemadbinstance error.



2) The alarm NoemdbInstance error is already defined in EMA system monitor GUI.


Action: Login to server 2 as user emadba and issue the command to stop the database instance

# su – emadba

tyEMA02$ /opt/sogdb/bin/stopdb

Result: Data base instance stopped on Node 2.

Action: Repeat the above steps on Node 1 to stop the database instance on Node 1.

Result: Database instance stopped on node 1 and alarm NoemadbInstanceError

raised on the OSS.

Post requisite:

1) Login to server 2 form user emadba and issue the command to start the emadb instance

# su – emadba

tyEMA02$ /opt/sogdb/bin/startdb

2) Repeat the above step on node 1 to start the ema db instance on Node 1.

1.1.2.2.3 To verify CannotLoginDBError - Users cannot log onto Oracle with the sysdba account using ‘‘sqlplus / as sysdba’’.

Description: The purpose of this test case is to verify the event CannotLoginDBError - Users cannot log onto Oracle with the sysdba account using ‘‘sqlplus / as sysdba’’.


1) The connectivity between EMA and OSS RC verified.

2) The Alarm CannotLoginDB is defined in EMA system monitor GUI


Action: Login to EMA using user emadba

# su - emadba

Result: User emadba successfully logged in

Action: try logging in to DB using ‘‘sqlplus / as sysdba’’ without specifying the SID.

tyEMA01$ sqlplus / as sysdba

Result: Unable to login to DB and alarm sent to OSS. Verify the alarm at OSS.

1.1.2.2.4 To verify CannotLoginUsingTNSError - Users cannot log onto Oracle as the sysdba account using TNS emadb or emadbdg.

Description: The purpose of this test case is to verify the event CannotLoginUsingTNSError - Users cannot log onto Oracle as the sysdba account using TNS emadb or emadbdg.


1) The connectivity between EMA and OSS RC verified.

2) The Alarm CannotLoginUsingTNSError already defined in EMA system monitor GUI.


Action: Login to EMA using user emadba

# su - emadba

Result: User emadba successfully logged in

Action: Login to sqlplus with specifying the TNS

tyEMA01$ sqlplus / as sysdba@emadb

Result: As the connection string is wrong, the user will not be able to login and the alarm will be sent to OSS. Verify the alarm from OSS.

1.1.2.2.5 To verify DataGuard:NoneVipError

Description: The purpose of this test case is to verify the alarm DataGuard:NoneVipError

Prerequisite: Following pre requisites needs to meet prior to execution of this test case:


The alarm DataGuard:NoneVipError is already defined in EMA system monitor GUI.

Procedure: Follow the steps mentioned as below:

Action: Login to EMA server 1 from user root and issue the below command to stop the EMA dataguard vip

# su – root


Result: The dataguard vip stopped on node 2

Action: Login to EMA server 2 from user root and issue the below command to stop the EMA dataguard vip

# su – root


Result: The dataguard vip stopped on node 2 and the alarm DataGuard:NoneVipError raised on the OSS. Also the alarm DataGuard:VipOnStandbyServerError will be raised.

Post requisites:

1) Login to server 1 from user root and issue the below command to start the dataguard vip

# su – root

# crm resource start dg-vip

2) Repeat the above step on server 2 to start the dataguard vip.

1.1.2.2.6 To verify DataGuard:VipOnStandbyServerError

Description: The purpose of this test case is to verify the alarm raised on the OSS when dg-vip is not running on standby server.



2) The alarm DataGuard:VipOnStandbyServerError already defined o the EMA system monitor GUI.

1.1.2.2.7 To verify DataGuard:NoObserverOnStandbyServerError

Description: the purpose of this test case is to verify the alarm DataGuard:NoObserverOnStandbyServerError.



2) The alarm DataGuard:NoObserverOnStandbyServerError already defined in EAM system monitor GUI.


Action: Login to server 2 as user root and restart the dataguard to view and verify the alarm

# rcopenais restart

Result: The dataguard will restart and the alarm DataGuard:NoObserverOnStandbyServerError will be raised on the OSS.

Note: Many other dataguard related alarms may also be raised as we are restarting the dataguard. These alarms will be ceased when the dataguard is started again, ignore these alarms.

1.1.2.2.8 To verify DataGuard:ObserverOnPrimaryServerError



2) The alarm DataGuard:NoObserverOnPrimaryServerError already defined in EAM system monitor GUI.


Action: Login to server 1 as user root and restart the dataguard to view and verify the alarm

# rcopenais restart

Result: The dataguard will restart and the alarm DataGuard:NoObserverOnPrimaryerverError will be raised on the OSS.

Note: Many other dataguard related alarms may also be raised as we are restarting the dataguard. These alarms will be ceased when the dataguard is started again, ignore these alarms.

1.1.2.2.9 To verify Dataguard:ToStandbyStatusError - The Data Guard status on the primary server is not ‘‘TO STANDBY’’.

Description: The purpose of this test case is to verify the event Dataguard:ToStandbyStatusError.


1) The connectivity between EMA and OSS verified

2) The alarm Dataguard:ToStandbyStatusError already deifned in system monitor GUI

Note: The procedure for this test case is still under discussion and will be updated after the clarifications.

1.1.2.2.10 To verify the Dataguard:DiskExhaustedError - Disk partitions for emadb or emadbdg are exhausted.

Description: The purpose of this test case is to verify the event the Dataguard:DiskExhaustedError which is sent to the OSS when Disk partitions for emadb or emadbdg are exhausted.


1) The connectivity between EMA and OSS successfully verified.

2) The alarm Dataguard:DiskExhaustedError already defined on the EMA system monitor GUI


Action: Fill the partition on which emadb or emadbdg is mounted woth some junk data till the partition is almost full

Result: The alarm Dataguard:DiskExhaustedError sent to the OSS

Post requisite: Delete all the Junk data that was added in this test case to EMA server to cease the alarm.

1.1.2.3 Database Alarm

1.1.2.3.1 To verify Database: DBMaintainScriptFailed - Database Maintain Script Failed

Description: The purpose of this test case is to verify the event Database: DBMaintainScriptFailed which is sent to the OSS when the Database maintainence script fails to run.

Prerequisite: None

Note: The risk factor for trigerring database related alarm manually is under internal discussion and this test case will be updated after the discussion.

1.1.2.3.2 To verify Database: ArchivelogBackupFailed - Archive log backup failed

Description: The purpose of this test case is to verify the event Database: ArchivelogBackupFailed which is sent to the OSS when the archieve log backup fails.

Prerequisite: None

Note: The risk factor for trigerring database related alarm manually is under internal discussion and this test case will be updated after the discussion.

1.1.3 PC /CA alarms

1.1.4 Hardware Alarms / Events

1.1.4.1 System Resources

1.1.4.1.1 To verify event System resources: CPU

Description: The purpose of this test case is to verify the alarm raised on the OSS when CPU usage has reached the threshold value.

Prerequisite: the following prerequisite needs to be met prior to execution of this test case:

1) The connectivity between EMA and OSS RC is sucessfuly verified.

Procedure: The procedure is under internal discussion and will be updated after that.

Result: The result will be added after the internal discussion

1.1.4.1.2 To verify event System resources: LoadAverage

Description: The purpose of this test case is to verify the alrms raised on the OSS when Load average has reached the threshold value.





1.1.4.1.3 To verify event System Reources:Disk

Description: The purpose of this test case is to verify the alarm raised on the OSS when the Disk usage has reached the max threshold value.





1.1.4.1.4 To verify event system resources: Swap

Description: The purpose of this tet cases is to verify the alarm raised on the OSS when the swap has reached the threshold value.





1.1.4.1.5 To verify System resources: Memory

Description: The purpose of this test case is to verify the event system resource:Memory.





1.1.4.1.6 To verify System resources: Interface

Description: The purpose of this test case is to verify the event system resources:Interface





1.1.4.1.7 To verify system resources: Process

Description: The purpose of this test case is to verify the event system resources:Process





1.1.4.1.8 To verify System resources: Local Device

Description: The purpose of this test case is to verify the event System resources:Local Device





how to test ema alarms

Documents