Each unique OID registered with the SNMP subsystem can only be mapped to one statistics parameter set type at any one time. An OID conflict occurs when two statistics parameter set types use the same static OID. This may happen simply by chance, e.g. two separate products inadvertently defined using the same base OID, or as a consequence of a product upgrade, e.g. two versions of the same service using the same OID. In general, when Rhino detects an OID conflict, it will deregister from SNMP all parameter set types mapped to that OID. However, in Rhino 3.1+, an exception is made to this general rule to facilitate online service upgrades.
Conflict Resolution During Service Online Upgrade
The online upgrade of a service typically involves installing a new version of the service, then activating that while simultaneously deactivating the old version. Once the old version has finished draining its active sessions, it can then be uninstalled, leaving only the new version in its place. A problem arises though if both old and new service versions use the same OIDs for their parameter set types, which, understandably, would be desirable if service statistics have not materially changed between versions.
With Rhino’s default behaviour, the OID conflict would cause the parameter set types for all conflicting OIDs to be deregistered while the conflict exists. However, to ensure that statistics availability via SNMP can be maintained during the period of a service upgrade, two services with the same base OID and the same statistics presentation alias (a service deployment descriptor attribute used for MIB generation) exhibit the following SNMP registration behaviour for any conflicting parameter set type OIDs:
-
On initial service deployment, the first service to be deployed will have its parameter set types registered. Services deployed later will have their conflicting parameter set types remain unregistered.
-
On node restart, the first service to be redeployed during boot will initially be chosen to have its parameter set type registered. (Due to the multi-threaded nature of component redeployment, this choice of service may be arbitrary, and could be different on different cluster nodes.)
-
The first service to be activated and transition to an actual state of
activewill have its parameter set types registered if they are not already. Conflicting parameter set types from another service will be deregistered as necessary to accommodate. -
If a service whose parameter set types are registered is deactivated and there is another service with an actual state of
active, then when the deactivating service’s actual state transitions fromstoppingtoinactiveits conflicting parameter set types will be deregistered, and the parameter set types of the active service will be registered in their place.
For clarification, the current registration for parameter set types with conflicting OIDs may only change:
-
when a service transitions to the
activeactual state where no other service is active; -
when a service transitions to the
inactiveactual state where another service isactiveorstopping; and -
when a service component is undeployed, which may remove a conflict completely.
When any of these events occur, conflicting parameter set type registrations are reevaluated and may or may not change as appropriate. At any other time, registrations stay as they are and do not change.
|
This special behaviour only occurs if an OID conflict only happens between service components with the same statistics presentation alias. If there is an OID conflict between services with different aliases, or between a service and any other type of component, this behaviour does not apply. |
|
Conflict resolution is intended only for the limited use case of an online service upgrade. Where no conflicting services are active, or more than one conflicting service is active at the same time, it is unpredictable which service will have its parameter set types registered after a node reboot. Consequently, this behaviour should not be relied on for general conflict resolution at any other time than a service upgrade. |
OID Conflict Alarms
When an OID conflict occurs between two parameter set types, Rhino will raise a rhino.snmp.duplicate-oid-mapping alarm.
This alarm may be suppressed for the special service conflict resolution behaviour using the system property snmp.suppress_service_oid_conflict_alarms.
If this system property is set to true, an alarm will not be raised when a service OID conflict can be temporarily resolved as described above, however a warning log message noting the conflict will still appear in the Rhino console log.
