DetachInterval is an optional parameter that is applicable to SAM, Adapter Platform, BIM, and all Domain Managers.

DetachInterval in a warm failover

In case of a warm failover (Business Impact Manager, IP Manager, and Server Manager), the DetachInterval determines how long the Active SAM server will wait before starting topology synchronization with the newly-promoted Active Domain Manager. This way, the previously Standby Domain Manager is allowed to settle in after initiating network monitoring. Both initiating network monitoring and topology synchronization with SAM are resource intensive operations, so the DetachInterval ensures that they do not happen at the same time. The default DetachInterval for Domain Managers is 300 seconds, except for IP Managers, the value is 480.

DetachInterval in a hot failover

In case of a hot failover (SAM and Adapter Platform), use the DetachInterval parameter to avoid the creation of orphaned events. This parameter controls the number of minutes between the enabling of the underlying Domain Managers and detaching the peer component during a failover. The default DetachInterval for SAM and Adapter Platform is 300 seconds.

Orphaned events are discarded, which should be avoided since the events the peer knows about, came from the recently enabled underlying Domain Managers. EMC recommends waiting for the synchronization of the underlying Managers to complete so that when the peer is removed as a source, the events do not become orphans.

After the specified interval, the Standby component deletes its Active sibling from its repository after a failover occurs and the roles of the components switch. The Standby component no longer needs to obtain its data from the failed component, since it is itself connected to the underlying Domain Managers after the failover.

The interval should allow enough time for the Standby component to synchronize its topology and event data directly from the underlying Domain Manager before deleting the sibling component. Therefore, it does not allow any window where data may be missing in the newly Active component.

Although the newly Active component will stabilize its data eventually, as smooth a transition as possible is imperative. Especially, in case of a too short detach interval, clearing and re-notifying existing notification will result in re-occurrences of notifications and may cause opening new tickets.

For example, when a connection from the Standby SAM to Active SAM is disabled and the Standby SAM becomes Active, the topology that came from the old Active SAM will be removed from the new Active SAM. This is why it is important that the new Active SAM establishes connections and completes synchronization with underlying analysis Domain Managers so that:

  • The old Active SAM is not the only source on notifications and topology in the new active SAM.

  • There is no premature notifications clearing and topology removal.

    The notifications and topology will stay in the new Active SAM, but the notification source and topology domain management will no longer list the old Active SAM. Instead, it will only list the source analysis Domain Managers.

    The Active component is one that participates in the connection set within the current deployment. Connections may be established between:

  • The Managers (Service Assurance Manager to Service Assurance Manager, Service Assurance Manager to Adapter Platform, Service Assurance Manager to IP Availability Manager, so on).

  • Or, between clients and the server, mainly the Global Console and the top-level Service Assurance Manager.

    A hot Standby component, on the other hand, synchronizes with the Active component and no other servers or clients are connected to it (unless required for some maintenance purpose).

    Note:

    Failover script files located in <BASEDIR>/smarts/actions and <BASEDIR/smarts/rules directories must not be modified.