Mitel Deutschland GmbH 68635RFP36U-01 사용자 설명서
SIP-DECT OM System Manual
264
7.15 OMM STANDBY
To perform OMM standby, two OpenMobility Managers must be provided in an OMM network. One
operates as the active OMM, and the other operates as the standby OMM.
operates as the active OMM, and the other operates as the standby OMM.
In the event that the RFP designated as the OMM fails, the other RFP, designated as the secondary
OMM automatically assumes the role of the OpenMobility Manager.
OMM automatically assumes the role of the OpenMobility Manager.
How OMM Standby works
During system start-up, each RFP retrieves either one (if no standby OMM is configured) or two (if OMM
Standby is configured) OMM IP addresses and both try to connect to each other. The active OMM
serves all connections from RFPs or DECT phones.
During system start-up, each RFP retrieves either one (if no standby OMM is configured) or two (if OMM
Standby is configured) OMM IP addresses and both try to connect to each other. The active OMM
serves all connections from RFPs or DECT phones.
During normal operations, both the active and the standby OMM are in contact and monitor each other’s
operational state. They continually exchange their current standby states and the standby OMM receives
a copy of any configuration changes on the active OMM. As long as both OMMs are in contact, their
databases are synchronized automatically.
operational state. They continually exchange their current standby states and the standby OMM receives
a copy of any configuration changes on the active OMM. As long as both OMMs are in contact, their
databases are synchronized automatically.
If the primary OMM fails, the OMM responsibilities are taken over by the standby OMM to maintain
operation. A “No Standby” warning is displayed on the OMM web interface, indicating that there are no
longer two functioning OMMs in the network or cluster. Configuration changes are made unsafely in this
situation.
operation. A “No Standby” warning is displayed on the OMM web interface, indicating that there are no
longer two functioning OMMs in the network or cluster. Configuration changes are made unsafely in this
situation.
If the active OMM fails, the inactive OMM recognizes this and begins to act as the active OMM, and
starts the web service.
starts the web service.
If the connection between the two OMMs fails, the network or cluster essentially breaks into two
operational parts. The standby OMM becomes the active OMM. At this point, the two OMMs cannot
detect one another and, therefore, cannot synchronize. When the connection between the two OMMs is
re-established, the synchronization of the OMMs forces one OMM to become the standby OMM again.
Once the recently failed OMM returns to service and becomes the inactive OMM, it does not resume the
role of active OMM.
operational parts. The standby OMM becomes the active OMM. At this point, the two OMMs cannot
detect one another and, therefore, cannot synchronize. When the connection between the two OMMs is
re-established, the synchronization of the OMMs forces one OMM to become the standby OMM again.
Once the recently failed OMM returns to service and becomes the inactive OMM, it does not resume the
role of active OMM.
7.15.1 CONFIGURING OMM STANDBY
Each RFP of the DECT system must be configured with two OMM IP addresses. Both OMM addresses
can be either configured via DHCP (see section 7.5.1) or with the OM Configurator (see section 7.6).
can be either configured via DHCP (see section 7.5.1) or with the OM Configurator (see section 7.6).
7.15.2 FAIL OVER SITUATIONS
Fail over occurs when:
•
an OMM error occurs on the active OMM.
•
the RFP acting as the active OMM is shut down or rebooted at the SSH console.
•
the OMM is rebooted in the web browser menu.
•
the active OMM is unreachable.
The standby OMM becomes the active OMM when:
•
the configured SIP Proxy/Registrar is reachable.
•
the other OMM has a larger IP Address while no OMM is active and both OMMs are in contact with
each other (normally at system startup).