SpectroSERVER Alarm Synchronization
The primary and secondary
SpectroSERVERs use a Global Alarm Service (GAS) connection to share alarm information. The
SpectroSERVERs 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
SpectroSERVERare generated rather than being created from events.
The process of alarm synchronization differs depending on whether the synchronization is from the primary
SpectroSERVERto the secondary
SpectroSERVERor 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
SpectroSERVERis running as a secondary
SpectroSERVER, it tries to open a GAS connection to the primary
SpectroSERVER. If the connection succeeds, the secondary
SpectroSERVERregisters 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
SpectroSERVERtries once each minute to connect until the primary
The Fault-Tolerant Alarm Service is enabled on both the primary and secondary servers for the secondary
SpectroSERVERto attempt to connect to the primary
SpectroSERVERfor alarm synchronization.
DX NetOps Spectrumuses 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
SpectroSERVERprocesses alarm updates from the primary
- The new primarySpectroSERVERalarms are added on the secondarySpectroSERVERand 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
- The alarm attribute updates from the primarySpectroSERVERare applied to the same alarms on the secondarySpectroSERVER. If an alarm is cleared on the primarySpectroSERVER, it is also cleared on the secondarySpectroSERVER.
- The isManaged and isNotHibernating attributes are updated for maintenance mode alarm synchronization.
Synchronization from the Secondary to the Primary
When the primary
SpectroSERVERcomes 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
SpectroSERVERcontrol the number and frequency of attempts. For more information, see Fault Tolerant Alarm Service (.vnmrc) Resources.
If the secondary
SpectroSERVERis 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
SpectroSERVERopens a GAS connection to the secondary
SpectroSERVERand retrieves all of its alarms.
After a Successful Connection:
- After it retrieves the list of alarms, the primarySpectroSERVERwrites the alarms to its database. PrimarySpectroSERVERstartup continues and these alarms are read from the database.
- The alarms from the secondarySpectroSERVERreplace 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 secondarySpectroSERVERwhile the primarySpectroSERVERwas down.
- The secondary alarm clear event (0x10715) generates for each alarm that cleared on the secondarySpectroSERVERwhile the primarySpectroSERVERwas 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 primarySpectroSERVERis 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 primarySpectroSERVERafter alarm synchronization has failed, run an Online Backup to synchronize the primary and secondarySpectroSERVERdatabases.