Takeover by standby processor – Sierra Video Yosemite User Manual
Page 75
505150 PROCESSORS
69
In Terminal Mode, this lapse could cause potential problems because the user often stays in submenus
longer. Because the standby processor starts up in the main terminal menu, it is unable to sync itself to a
submenu and any information the user is trying to submit will be lost. To try to prevent out-of-sync
problems from occurring, every time the standby processor comes online, the master processor’s terminal
protocol displays a message to the user that a standby processor is now available, and asks him to press
the “Control-C key combination”. After control-c is pressed, the routing switcher configuration screen is
displayed.
Takeover by Standby Processor
As aforementioned, both processors monitor the health of the other processor. If the standby processor
detects that the master processor is sick, or if it detects that the other processor is not acting as the
master for some reason, the standby processor will attempt to take over control of the system as the new
master processor.
Furthermore, if the master processor has determined that it is “sick” or if any of the following behavior
occurs in the master processor, it will shut itself down and allow the standby processor to take over:
Unexpected processor interrupts.
Processor data bus errors.
Software integrity check failures.
Manual takeover initiation by the user via a host protocol command or terminal port “T”
screen command
If the standby processor has determined that it is “sick” by flashing LEDd, it will refuse to take on the job
of master processor, even if the other processor is not present. A processor can only be master processor
when it thinks itself is okay and operational.
Therefore, the master processor will never flash LEDd. If the master processor thinks it is “sick”, it will
relinquish control to the standby processor. The standby processor will normally never flash LEDf, but will
instead take over as master processor if it detects that the master is having problems. However, if the
standby processor also thinks it is sick, it will flash both LEDd and LEDf, and will not take over as master
processor. If both processors are sick, they can both remain in a standby state, rendering the routing
switcher inoperative.
When the standby processor takes over, all control outputs (in particular, crosspoint control and serial
port transmit data) are switched over to the crosspoint matrices for all outputs to make sure that the actual
crosspoint state matches the new master processor state.
Normally, this will cause no change in the crosspoint state. However, if the new master had not yet
completed synchronization with the old master before it took over control, it is possible that some
crosspoints will change state. The new master processor also sends the state of all crosspoints to all
control panels but not to ports running host protocol. Every port that is running host protocol will receive a
“G REDUNDANT_PROCESSOR” command, with the
software, upon receiving such a command, should assume that any data it has cached from the previous
master may be invalid. This includes crosspoint data, panel configuration data, and any other data. It
should request the data again from the new master processor.
At takeover, if synchronization had not been completed, the new master also resets all control panels
because it is the only method to find out what types of control panels are present. Finally, the new master
begins normal operation.
With this activity taking place at takeover, users may notice a few seconds where control panels, host and
terminal commands have a delayed response.
At takeover, the master processor’s “terminal protocol” displays a message to the user to indicate that a
new master processor is in control. This serves as a clear notification to the user that a takeover has
occurred.