Appendix D: N-Command Failover Configuration
Appendix D: N-Command Failover Configuration
Introduction
You can configure N-Command for failover support by establishing a master/slave relationship between two
N-Command devices. Once properly configured, the system behaves as follows:
If a master unit fails, the slave unit initiates SVSI system services and assumes the eth0/eth1 IP addresses of
the master unit.
Any third-party controller communicating with the N-Command detects the failover only as a momentary
disruption because the slave assumes the master’s old IP addresses.
When the master is back on-line, it overrides the slave and resumes control.
Once the master resumes control, the slave releases the assumed IP addresses and returns to monitoring the
master’s status.
NOTE: The failover feature is supported by the N8002 and N8012 N-Command devices (not by the N8001).
Needed equipment
Required equipment for an N-Command master/slave system includes:
Two N8002/N8012 N-Command units
Network cables, power source, computer with web browser, etc.
Connection Diagram
All communication between the two N-Command units is performed through their eth0 and eth1 connections and
binded to the third IP address. Each N-Command monitors each other’s health. See Figure 54
.
FIG. 54 Connection Diagram
This means during normal operation the master eth0 and eth1 card will have at least two IP address: one for normal
Encoder/Decoder management and another for master/slave communication. When the slave takes control, it
assumes all the IP addresses of the master except for the third IP address of each card.
General Functionality
Every minute, the master communicates with the slave, and the slave communicates with the master. The
communication between the two determines if a failover scenario has occurred or if it is time to sync the databases.
All communication is performed through https master/slave web services. See the Failover Scenarios
section on
page 58 for more details on failover conditions.
During master > slave communication, if the master detects the slave has tried to take control, and the
master’s own databases and services are good, then the master will override the slave, and the slave will shut
down most system services and begin syncing with the master. The most common reason a slave may have
taken control with a good master is if the slave or master (or both) were disconnected from the network.
During slave>master communication, the slave is asking the master for its system health status. Three bad
health reports (including a non-communicative master) will trigger a failover. Every ten minutes, if the master
says its database is good, the slave asks for a copy of the database. The master generates, compresses, and
To Next Page
Loading...
Need help?
General
