SpectroSERVER Alarm Synchronization

Contents
casp1032
The primary and secondary
SpectroSERVER
s use a Global Alarm Service (GAS) connection to share alarm information. The
SpectroSERVER
s use the alarm information to synchronize alarms. This synchronization helps to prevent duplicate alarms.
Options for fault-tolerant alarm synchronization include enablement of the service and debug logging. Settings in the .vnmrc file control these options. For more information, see Fault Tolerant Alarm Service (.vnmrc) Resources.
The correlations are not preserved because the alarms on the secondary
SpectroSERVER
are generated rather than being created from events.
The process of alarm synchronization differs depending on whether the synchronization is from the primary
SpectroSERVER
to the secondary
SpectroSERVER
or from the secondary to the primary. The following sections describe each of these scenarios:
  • Synchronization from the Primary to the Secondary SpectroSERVER
  • Synchronization from the Secondary to the Primary SpectroSERVER
Synchronization from the Primary to the Secondary
SpectroSERVER
If the
SpectroSERVER
is running as a secondary
SpectroSERVER
, it tries to open a GAS connection to the primary
SpectroSERVER
. If the connection succeeds, the secondary
SpectroSERVER
registers to receive alarm updates from the primary
SpectroSERVER
. The secondary server remains connected to the primary and continues to receive alarm updates as they occur on the primary server. Otherwise, the secondary
SpectroSERVER
tries once each minute to connect until the primary
SpectroSERVER
becomes active.
The Fault-Tolerant Alarm Service is enabled on both the primary and secondary servers for the secondary
SpectroSERVER
to attempt to connect to the primary
SpectroSERVER
for alarm synchronization.
DX NetOps Spectrum
uses the ftasv_enabled parameter in the .vnmrc file to sync the alarms. By default, the ftasv_enabled parameter is set to true. For more information, see Fault Tolerant Alarm Service (.vnmrc) Resources.
The following diagram describes how the secondary
SpectroSERVER
processes alarm updates from the primary
SpectroSERVER
:
SPEC--secondary_startup
  • The new primary
    SpectroSERVER
    alarms are added on the secondary
    SpectroSERVER
    and marked as 'stale'. A new alarm replaces an existing alarm if they are equivalent. You can determine whether the alarms are equivalent by verifying the following parameters:
    • Unique Alarm (IDs)
    • Model Handle
    • Probable Cause
    • Alarm Discriminators
    Two alarms are considered equivalent if they have the same ID. Alarms that are on the same model (that is, they have the same model handle) and that have the same probable cause are also considered equivalent unless they have different alarm discriminators.
  • The alarm attribute updates from the primary
    SpectroSERVER
    are applied to the same alarms on the secondary
    SpectroSERVER
    . If an alarm is cleared on the primary
    SpectroSERVER
    , it is also cleared on the secondary
    SpectroSERVER
    .
  • The isManaged and isNotHibernating attributes are updated for maintenance mode alarm synchronization.
Synchronization from the Secondary to the Primary
SpectroSERVER
When the primary
SpectroSERVER
comes online after a failure or planned maintenance, it connects to the secondary
SpectroSERVER
, and it gets all available alarms. If the first connection attempt fails, the primary server can make multiple connection attempts to synchronize. The ftasv_max_conn_retry_count and ftasv_conn_retry_interval parameters in the .vnmrc file of the primary
SpectroSERVER
control the number and frequency of attempts. For more information, see Fault Tolerant Alarm Service (.vnmrc) Resources.
If the secondary
SpectroSERVER
is not running when the primary server attempts to connect to it, the primary exhausts its synchronization attempts. The result is a delay in starting the primary. This delay is unavoidable because it occurs before model activation. Avoid the situation by verifying that the secondary server is running when the primary starts. You can also decrease the retry count or interval size to reduce the potential delay. Or you can disable the Fault Tolerant Alarm Service using the ftasv_enabled parameter in the .vnmrc file.
The following diagram describes how the primary
SpectroSERVER
opens a GAS connection to the secondary
SpectroSERVER
and retrieves all of its alarms.
SPEC--primary_startup
After a Successful Connection:
  • After it retrieves the list of alarms, the primary
    SpectroSERVER
    writes the alarms to its database. Primary
    SpectroSERVER
    startup continues and these alarms are read from the database.
  • The alarms from the secondary
    SpectroSERVER
    replace the alarms that are stored in the primary database at retrieval.
  • All alarms that are read from the database are processed and asserted on the correct models.
  • The secondary 'alarm set' event (0x10714) generates for each new alarm that was generated on the secondary
    SpectroSERVER
    while the primary
    SpectroSERVER
    was down.
  • The secondary alarm clear event (0x10715) generates for each alarm that cleared on the secondary
    SpectroSERVER
    while the primary
    SpectroSERVER
    was down.
No synchronization occurs for blue and gray alarms. Synchronization occurs for brown alarms, but not for WA_Link models. The WA_Link model exception only applies to brown alarms.
After a Failed Synchronization:
  • If alarm synchronization fails when the primary
    SpectroSERVER
    is attempting to connect to the secondary, the primary starts up, but an event and critical alarm (0x10c35) are generated on the primary LocalLscpe model. The event and alarm include the reason for the failure of each attempt. To continue running the primary
    SpectroSERVER
    after alarm synchronization has failed, run an Online Backup to synchronize the primary and secondary
    SpectroSERVER
    databases.