
Avaya Media Processing Server Series System Reference Manual
Page 284 # P0602477 Ver: 3.1.11
4. Verify that the MPS and COMMON components started on the secondary
are running the correct processes that were running on the primary (i.e., if
MPS comp was running confmgr and/or faxmgr on the primary they must
now be running on the secondary).
Failback
Initiate a failback to the failed primary. This should be done only after the above
failover was successful (preferably wait at least 60 seconds). The steps to be taken
depend on the steps performed to cause the failover:
• If the Ethernet was unplugged to cause the failover then:
• pre MPS2.1 PB10 plug the Ethernet cable back in and restart the MPS.
• post MPS2.1 PB10 simply plug the Ethernet cable back in.
• If the primary was shutdown then reboot it.
• If power was removed from the primary then reapply power and boot the
system (fixing the file system if necessary).
• If the MPS software was stopped then restart it. Start SRP on the Primary
MPS/node (via services on windows and /etc/rc3.d/S20vps.startup script on
Solaris).
In all of the above cases a failback will either already be initiated upon restart of the
MPS software if the automatic failback mechanism was enabled, or will require the
user to enter the following vsh command from the previously failed primary to
manually initiate the failback:
vsh> trip auto-failback hard
Follow these steps to verify that the failback was successful:
1. On the secondary, verify that SRP and COMMON are in the RUNNING
state while all MPS components are in the STANDBY state using:
vsh> srp -status
2. On the secondary, verify that the following alarm appears for every MPS
component the secondary is configured for:
Fri Jun 10 11:53:06 <trip> 10002 Severity 1 Comp #mps.10/tmsi01
Entering STANDBY state
In the first line, #mps.10 is the standby MPS.
3. On the primary verify that SRP, COMMON, and all MPS components are
in the RUNNING state using:
vsh> srp -status
Komentáře k této Příručce