Avaya S8700 - Troubleshooting a Duplicated Server

Alarms, Errors, and Troubleshooting
555-233-143
4-10 Issue 1 May 2002
Troubleshooting a Duplicated Server
The sections, ‘‘Initialization and Recovery’’ on page 3-1, ‘‘IP-SVR (IP Server
Interface)’’ on page 8-959, and ‘‘IPSV-CTL (Ipserver Interface Control)’’ on page
8-950, contain procedures for troubleshooting specific problems with servers and
IPSIs.
!
CAUTION:
Follow normal escalation procedures before shutting down either an
application or the entire system. Then, execute the shutdown only when
advised by the appropriate tier’s Services representative.
!
CAUTION:
MultiVantage application resets can have wide-ranging disruptive effects.
Unless you are familiar with resetting the system, follow normal escalation
procedures before attempting a demand reset.
If a spontaneous server interchange has occurred, assume that a serious fault
has occurred on the current standby server. The following symptoms indicate that
a spontaneous server interchange has taken place:
■ A SYSTEM error is logged in the Error log.
■ An interchange entry is recorded in the initcauses log.
The occurrence of a recent interchange is displayed in the Bash shell’s server
screen.
There are two possible causes of a spontaneous interchange:
■ Major hardware failure
■ Failed recovery that has been software-escalated
If the interchange was fault-driven, there are two ways of finding the cause.
■ Using alarm and error logs in conjunction with the timestamp described
below.
After a spontaneous server interchange has occurred, the alarm log retains
a record of any MAJOR ON-BOARD alarm against a server component
that took place before the interchange. This record is retained for 3 hours
and may indicate the cause of the interchange when testing is not possible
or conclusive. Other information in the error log may also be helpful.
■ Testing the standby server when the logs do not identify the problem.
Start by determining the time of the interchange. (From the server’s Bash shell
prompt, enter server, and refer to the Elapsed Time Since Last Spont.
Interchange field.) Then, examine the alarm and error logs as described in
the following section. If this does not identify the problem, proceed to the next
section, which describes a sequence of tests of the standby server.