how to test ema alarms
DESCRIPTION
How to Test EMA Alarms - Ericsson Multi Activation NodeTRANSCRIPT
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
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</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.
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The OSSRC and EMA integration has been verified.
2) The Alarm DBInterface:OracleServerUnavailableError has been defined in EMA System monitor GUI.
Procedure: Follow the procedure as below:
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.
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The OSSRC & EMA integration has been verified
2) The Alarm MOHandler:RoutingFailed has been defined in EMA System monitor GUI
Procedure: Follow the procedure as below:
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
sogadm> emaserver –domain PL status
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.
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The OSSRC & EMA integration has been verified
2) The Alarm MOHandler:RegistrationWarning has been defined in EMA System monitor GUI.
Procedure: Follow the procedure as below:
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:
1) The OSSRC & EMA integration has been verified
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.
sogadm> emaserver –domain PL stop
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> 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.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.
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The OSSRC & EMA integration has been verified.
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
Please input alarmModelDescription [FDSAuthority:UserNotAllowed]:
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.
# /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
[MOHandler:CorrectUnRegistration]:
FDSAuthority:UserNotAllowed
Please input alarmActiveDescription
[MOHandler:CorrectUnRegistration]:
FDSAuthority:UserNotAllowed
Please input ituAlarmEventType [10]: 10
Please input ituAlarmProbableCause [614]: 614
Then, need to check configuration.
# /opt/sog/bin/alarmmapping –l
Then, need to check whether original alarm (FDSAuthority:UserNotAllowed) can see on OSS-RC
# su - sogadm
sogadm> telnet 0 3300
Enter command: LOGIN:sogadm:sog;
Enter command: LOGOUT;
1.1.1.3.6 Invalid unregistration
Description: The MO name is already unregistered in the FDSServer process.
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The OSSRC & EMA integration has been verified.
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.
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The OSSRC & EMA integration has been verified.
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> cd /var/sog/data/database
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> cd /var/sog/data/database
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.
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
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.
# /opt/sog/bin/alarmmapping –l
3) 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]:
FDSConfigurationManager:NotificationWarning
Please input alarmModelDescription [FDSAuthority:UserNotAllowed]:
FDSConfigurationManager:NotificationWarning
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.
4) Generate the fake alarm by sogadm user using following procedure toward OSS-RC.
# su - sogadm
sogadm> telnet 0 3300
Enter command: LOGIN:sogadm:sog;
Enter command: LOGOUT;
Result: The FDSConfigurationManager:NotificationWarning 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.
# /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
[FDSConfigurationManager:NotificationWarning]:
FDSAuthority:UserNotAllowed
Please input alarmActiveDescription
[FDSConfigurationManager:NotificationWarning]:
FDSAuthority:UserNotAllowed
Please input ituAlarmEventType [10]: 10
Please input ituAlarmProbableCause [614]: 614
Then, need to check configuration.
# /opt/sog/bin/alarmmapping –l
Then, need to check whether original alarm (FDSAuthority:UserNotAllowed) can see on OSS-RC
# su - sogadm
sogadm> telnet 0 3300
Enter command: LOGIN:sogadm:sog;
Enter command: LOGOUT;
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.
Procedure: Follow the procedure as below:
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:
1) The OSSRC & EMA integration has been verified.
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
Enter command: 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.
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The OSSRC & EMA integration has been verified.
2) The Alarm FDSAuthority:UserLoggedIn has been defined in EMA System monitor GUI.
Procedure: Perform the steps as below:
Open a terminal application program
1) Telnet to EMA PN node as sogadm user at CAI port 3300
2) In the Enter command prompt enter
Enter command: LOGIN:sogadm:sogadm;
3) After verified the alarm enter the below command to logout
Enter command: LOGOUT;
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.
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The OSSRC & EMA integration has been verified.
2) The Alarm FDSAuthority:UserLoggedOut has been defined in EMA System monitor GUI.
Procedure: Perform the steps as below:
Open a terminal application program
1) Telnet to EMA PN node as sogadm user at CAI port 3300
2) In the Enter command prompt enter
Enter command: LOGIN:sogadm:sogadm;
3) After verified the alarm enter the below command to logout
Enter command: LOGOUT;
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
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The OSSRC & EMA integration has been verified.
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
sogadm> emaserver –domain PL status
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:
1) The OSSRC & EMA integration has been verified.
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.
4) Check the OSSRC for the alarm message.
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 stop
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
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) "FDSComponentManager:FailedToSaveConfig" alarm is already defined on System Monitor GUI and the alarm is ceased before verification.
Procedure: Perform the steps as below:
1) Log in to EMA AS (PN) as root user.
2) Check current ESA configuration (FDSAuthority:UserNotAllowed and FDSComponentManager:FailedToSaveConfig) using the following command.
# /opt/sog/bin/alarmmapping -l
3) 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]:
FDSComponentManager:FailedToSaveConfig
Please input alarmModelDescription [FDSAuthority:UserNotAllowed]:
FDSComponentManager:FailedToSaveConfig
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.
4) Generate the fake alarm by sogadm user using following procedure toward
OSS-RC.
# su - sogadm
sogadm> telnet 0 3300
Enter command: LOGIN:sogadm:sog;
Enter command: LOGOUT;
Result: The FDSComponentManager:FailedToSaveConfig 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.
# /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
[FDSComponentManager:FailedToSaveConfig]:
FDSAuthority:UserNotAllowed
Please input alarmActiveDescription
[FDSComponentManager:FailedToSaveConfig]:
FDSAuthority:UserNotAllowed
Please input ituAlarmEventType [10]: 10
Please input ituAlarmProbableCause [614]: 614
Then, need to check configuration.
# /opt/sog/bin/alarmmapping -l
Then, need to check whether original alarm (FDSAuthority:UserNotAllowed) can see on OSS-RC
# su - sogadm
sogadm> telnet 0 3300
Enter command: LOGIN:sogadm:sog;
Enter command: LOGOUT;
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.
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 FDSComponentManager:information has been defined in EMA System monitor GUI
Procedure: Follow the procedure as below:
1) Telnet to EMA node as sogadm user
2) As sogadm user re-start FDS-PL plugin
sogadm> emaps -k FDS-PL
3) Check the OSSRC for the alarm message.
4) Check that all the plugins become active in the processing node
sogadm> emaserver status
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:
1) The OSSRC & EMA integration has been verified.
2) The Alarm FDSComponentManager:MORequestFailed has been defined in EMA System monitor GUI
Procedure: Perform the steps as below:
1) Log in to EMA as sogadm user and make sure CAI component is alive
sogadm> emaps
sogadm> emaserver –domain PL status
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”.
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The OSSRC & EMA integration has been verified.
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
3) Check the OSSRC for the alarm message.
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 :
1) The OSSRC & EMA integration has been verified.
2) The Alarm FDSComponentManager:RebuildingStructuresInfo has been defined in EMA System monitor GUI
Procedure: Follow the procedure as below:
1) Telnet to EMA node as sogadm user
2) As sogadm user re-start the FDS server component
sogadm> emaps -k FDS-PL
3) Check the OSSRC for the alarm message.
4) Check that the all the plugin in the PL has become active
sogadm> emaserver status
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.
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) "GUIDriver:LicenceKeyError" alarm is already defined on System Monitor GUI and the alarm is ceased before verification.
Procedure: Perform the steps as below:
1) Log in to EMA AS (PN) as root user.
2) Check current ESA configuration (FDSAuthority:UserNotAllowed and GUIDriver:LicenceKeyError) using the following command.
# /opt/sog/bin/alarmmapping -l
3) 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]:
GUIDriver:LicenceKeyError
Please input alarmModelDescription [FDSAuthority:UserNotAllowed]:
GUIDriver:LicenceKeyError
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.
4) Generate the fake alarm by sogadm user using following procedure toward
OSS-RC.
# su - sogadm
sogadm> telnet 0 3300
Enter command: LOGIN:sogadm:sog;
Enter command: LOGOUT;
Result: The GUIDriver: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.
# /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
[GUIDriver:LicenceKeyError]: FDSAuthority:UserNotAllowed
Please input alarmActiveDescription
[GUIDriver:LicenceKeyError]: FDSAuthority:UserNotAllowed
Please input ituAlarmEventType [10]: 10
Please input ituAlarmProbableCause [614]: 614
Then, need to check configuration.
# /opt/sog/bin/alarmmapping -l
Then, need to check whether original alarm (FDSAuthority:UserNotAllowed) can see on OSS-RC
# su - sogadm
sogadm> telnet 0 3300
Enter command: LOGIN:sogadm:sog;
Enter command: LOGOUT;
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
Procedure: Perform the steps as below:
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
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
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
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The OSSRC & EMA integration has been verified.
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.
Prerequisite: The following prerequisites need to be met prior to execution of this test case:
1) "ProcEngine:ConfigurationWriteFailure" alarm is already defined on System Monitor GUI and the alarm is ceased before verification.
Procedure: Perform the below procedure:
1) Log in to EMA AS (PN) as root user.
2) Check current ESA configuration (FDSAuthority:UserNotAllowed and
ProcEngine:ConfigurationWriteFailure) using the following command.
# /opt/sog/bin/alarmmapping -l
3) 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]:
ProcEngine:ConfigurationWriteFailure
Please input alarmModelDescription [FDSAuthority:UserNotAllowed]:
ProcEngine:ConfigurationWriteFailure
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.
4) 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 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.
# /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
[ProcEngine:ConfigurationWriteFailure]:
FDSAuthority:UserNotAllowed
Please input alarmActiveDescription
[ProcEngine:ConfigurationWriteFailure]:
FDSAuthority:UserNotAllowed
Please input ituAlarmEventType [10]: 10
Please input ituAlarmProbableCause [614]: 614
Then, need to check configuration.
# /opt/sog/bin/alarmmapping -l
Then, need to check whether original alarm (FDSAuthority:UserNotAllowed) can see on OSS-RC
# su - sogadm
sogadm> telnet 0 3300
Enter command: LOGIN:sogadm:sog;
Enter command: LOGOUT;
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.
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) "ProcEngine:LicenceKeyError" alarm is already defined on System Monitor GUI and the alarm is ceased before verification.
Procedure: Perform the steps as below:
1) Log in to EMA AS (PN) as root user.
2) Check current ESA configuration (FDSAuthority:UserNotAllowed and
ProcEngine:LicenceKeyError) using the following command.
# /opt/sog/bin/alarmmapping -l
3) 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?
1.1.1.10 (y/n):y
Please input alarmSeverity [6]: 6
Please input alarmModelDescription [FDSAuthority:UserNotAllowed]:
ProcEngine:LicenceKeyError
Please input alarmModelDescription [FDSAuthority:UserNotAllowed]:
ProcEngine:LicenceKeyError
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.
4) Generate the fake alarm by sogadm user using following procedure toward
OSS-RC.
# su - sogadm
sogadm> telnet 0 3300
Enter command: LOGIN:sogadm:sog;
Enter command: LOGOUT;
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.
# /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
[ProcEngine:LicenceKeyError]: FDSAuthority:UserNotAllowed
Please input alarmActiveDescription
[ProcEngine:LicenceKeyError]: FDSAuthority:UserNotAllowed
Please input ituAlarmEventType [10]: 10
Please input ituAlarmProbableCause [614]: 614
Then, need to check configuration.
# /opt/sog/bin/alarmmapping -l
Then, need to check whether original alarm (FDSAuthority:UserNotAllowed) can see on OSS-RC
# su - sogadm
sogadm> telnet 0 3300
Enter command: LOGIN:sogadm:sog;
Enter command: LOGOUT;
1.1.1.10.1 To verify event ProcEngine:UserNotAllowed
Description: The purpose of this test event ProcEngine:UserNotallowed
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
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
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The connectivity between EMA and OSS RC is successfully verified.
2) The alarm ProcEngine:LoadSubPluginError is already verified in EMA system monitor gui.
Note: It is not possible to trigger this alarm manually.
1.1.1.10.3 To verify event ProcEngine:LicenceExpiring
Description: The purpose of this test case is to verify the event ProcEngine:LicenceExpiring
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The connectivity between EMA and OSS RC is successfully verified.
2) The alarm ProcEngine:LicenceExpiring is already verified in EMA system monitor gui.
Note: It is not possible to trigger this alarm manually.
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.
Note: It is not possible to trigger this alarm manually.
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
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
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:
1) The OSSRC & EMA integration has been verified.
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.
7) Check the OSSRC for the alarm message.
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.
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The OSSRC & EMA integration has been verified.
2) The Alarm Mmllp:LinkManagerConnectionFailure has been defined in EMA System monitor GUI
Procedure: Perform the steps 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) 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)
1) Check the OSSRC for the alarm message.
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
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The OSSRC & EMA integration has been verified.
2) The Alarm LogWriter:LoadFileStopped has been defined in EMA System monitor GUI
Procedure: Perform the steps as below:
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
1) The OSSRC & EMA integration has been verified.
2) The Alarm Failed to load Log file. has been defined in EMA System monitor GUI
Procedure: Perform the steps as below:
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
Post requisite: After this test case finish, test engineer needs to return to original configuration as follows.
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.
Prerequisite: The following prerequisites need to be met prior to execution of this test case:
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
Procedure: Follow the procedure as below
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
Prerequisite: The following prerequisite needs to be met prior to the execution of this test case:
1) The connectivity between EMA and OSS RC is verified.
2) The alarm for event SOS receiver stopped is already defined in EMA.
Procedure: Follow the procedure as below
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.
Prerequisite: The following prerequisite needs to be met prior to the execution of this test case:
1) The connectivity between EMA and OSS RC is verified.
2) The alarm for event SOS consumer stopped is already defined in EMA.
Procedure: Follow the procedure as below
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
1) The connectivity between EMA and OSS RC is verified.
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
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The connectivity between EMA and OSS RC is successfully verified.
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
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The connectivity between EMA and OSS RC is successfully verified.
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
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The connectivity between EMA and OSS RC is successfully verified.
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.
Prerequisite: The following prerequisites needs to be met prior to execution of this test case:
1) The connection between OSS- RC and EMA is verified
2) The alarm LVS:ExternalVIPResourceStopped configured in EMA system monitor GUI
Procedure: Follow the procedure as below:
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.
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
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: Login to EMA server 1 as user root
Result: user root logged in
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.
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 ExternalPingResourceStopped already define in the EMA system monitor GUI
Procedure: Perform the steps as below:
Action: Login to EMA server 1 as user root
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
resource ping-external-clone is running on: tyEMA02
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.
resource ping-external-clone is running on: tyEMA01
resource ping-external-clone is running on: tyEMA02
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:
1) The connectivity between EMA and OSS RC verified
2) The alarm InternalPingResource already defined on the EMA system monitor GUI
Procedure:
Action: Login to EMA server 1 as user root
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:
1) The connectivity between EMA and OSS RC verified
2) The alarm ClusterMonitorResource already defined in the system monitor gui
Procedure:
Action: Login to EMA server 1 as user root
Result: user root logged in
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:
1) The connectivity between EMA and OSS RC verified
2) The alarm ClusterMonitorResource already defined in the system monitor gui
Procedure:
Action: Login to EMA server 1 as user root
Result: user root logged in
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:
1) The connectivity between EMA and OSS RC verified
2) The alarm OracleDataGuardRoleMonitorResource already configured 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 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:
1) The connectivity between EMA and OSS RC verified
2) The alarm OracleDataGuardObserverMonitorResource already defined in EMA system monitor GUI
Procedure:
Action: Login to server 1 as user root
Result: User root logged in
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: Login to EMA server 1 as user root
Result: User root logged in
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
2) Verify that the resource is successfully started
# 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:
1) The connectivity between EMA and OSS RC verified
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:
1) The connectivity between EMA and OSS RC verified
2) The alarm OracleEMALOGVIPResourceStopped already defined in the system monitor gui
Procedure:
Action: Login to server 1 as user root
Result: User root logged in
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: Login to EMA server 1 as user root
Result: User root logged in
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:
1) The connectivity between EMA and OSS RC verified
2) The alarm NFSVIPResourceStopped successfully defined on the EMA system monitor GUI
Procedure:
Action: Login to ema server 1 as user root
Result: user root logged in
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
Result: user root logged in
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:
1) The connectivity between EMA and OSS RC is verified
2) The alarm OrchestratorFileSystemResourceStopped already defined on the EMA system monitor GUI
Procedure:
Action: Login to EMA server 1 as user root
Result: User root logged in
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:
1) The connectivity between EMA and OSS RC is verified
2) The alarm NfsinfoFileSystemResourceStopped is already defined on the EMA system monitor GUI.
Procedure:
Action: Login to EMA server 1 as user root
Result: User root logged in
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
2) Verify that the resource is successfully started
# 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:
1) The connectivity between EMA and OSS RC is verified
2) The alarm BackupFileSystemResourceStopped already defined on the EMA system monitor GUI
Procedure:
Action: Login to EMA server 1 as user root
Result: User root logged in
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:
1) The connectivity between EMA and OSS RC verified
2) The alarm AgentdataFileSystemResourceStopped already defined in the EMA system monitor GUI
Procedure:
Action: Login to server 1 as user root
Result: User root logged in
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
2) Verify that the resource is successfully started by executing the command
# 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:
1) The connectivity between EMA and OSS RC is verified
2) The alarm EmalogFileSystemResourceStopped 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 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
2) Verify that the resource is successfully started by executing the command
# 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:
1) The connectivity between EMA and OSS RC verified
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.
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The connectivity between EMA and OSS RC verified
2) The alarm NoemdbInstance error is already defined in EMA system monitor GUI.
Procedure: Follow the procedure as below
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’’.
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The connectivity between EMA and OSS RC verified.
2) The Alarm CannotLoginDB is defined in EMA system monitor GUI
Procedure: Follow the procedure as below:
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.
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The connectivity between EMA and OSS RC verified.
2) The Alarm CannotLoginUsingTNSError already defined in EMA system monitor GUI.
Procedure: Follow the procedure as below:
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:
1) The connectivity between EMA and OSS RC verified
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
# crm resource stop dg-vip
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
# crm resource stop dg-vip
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.
Prerequisite: The following prerequisites need to be met prior to execution of this test case:
1) The connectivity between EMA and OSS RC is verified
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.
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The connectivity between EMA and OSS RC is verified
2) The alarm DataGuard:NoObserverOnStandbyServerError already defined in EAM system monitor GUI.
Procedure: Follow the procedure as below
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
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The connectivity between EMA and OSS RC is verified
2) The alarm DataGuard:NoObserverOnPrimaryServerError already defined in EAM system monitor GUI.
Procedure: Follow the procedure as below
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.
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
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.
Prerequisite: The following prerequisite needs to be met prior to execution of this test case:
1) The connectivity between EMA and OSS successfully verified.
2) The alarm Dataguard:DiskExhaustedError already defined on the EMA system monitor GUI
Procedure: Follow the procedure as below:
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.
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.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.
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.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.
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.5 To verify System resources: Memory
Description: The purpose of this test case is to verify the event system resource:Memory.
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.6 To verify System resources: Interface
Description: The purpose of this test case is to verify the event system resources:Interface
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.7 To verify system resources: Process
Description: The purpose of this test case is to verify the event system resources:Process
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.8 To verify System resources: Local Device
Description: The purpose of this test case is to verify the event System resources:Local Device
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