High availability
The FortiNAC high availability solution consists of a common management process, supporting scripts, and configuration and monitoring options in the admin UI. High availability can be used to ensure redundancy for FortiNAC Server, FortiNAC Control Server and FortiNAC Application Server pairs, and FortiNAC Control Manager.
The high availability management process provides messaging between the primary and secondary appliances. The process mirrors critical information, controls services, and performs system maintenance functions on all appliances. The management process also manages and determines which server is in control. It starts the secondary appliances in the event of a failover.
Supporting scripts determine whether the database replication is working. These scripts are also used to restore the database and/or files from the secondary to the primary and restart the primary server.
Database synchronization is handled by MySql replication to provide complete data integrity. For additional information on the MySql replication see http://dev.mysql.com/doc/refman/4.1/en/replication.html.
The high availability diagrams shown under Server communication define two possible high availability configurations usingFortiNAC Control Server and FortiNAC Application Server pairs. The first diagram illustrates the use of a shared IP address or host name that is moved between appliances during a failover and recovery. This provides the administrator with a single point of management access regardless of which appliance is in control. To use a shared IP address all of the appliances must be in the same subnet on the network. See Using a shared IP address (Layer 2).
The second diagram displays a high availability setup in which the appliance are on different subnets. To leverage high availability with appliances on separate subnets do not include a shared IP as part of the high availability configuration. If you are using a FortiNAC Control Server and FortiNAC Application Server pair and you are not using a shared IP address, during failover both appliances will failover to their corresponding secondary appliances regardless of which one actually failed. If you are using a shared IP address only the appliance that failed will failover to the secondary. See Servers on different subnets (Layer 3).
|
In a high availability configuration eth1 on the server is disabled until that server is in control. For example, eth1 on the secondary server is disabled until the primary server fails over and the secondary takes control. |
|
|
It is recommended that you use a Shared IP address in your high availability configuration whenever possible. This prevents the administrator from having to use separate IP addresses to manage the servers that are in control and alleviates communication issues with the Persistent Agent. |
|
|
If your primary and secondary servers are on different subnets, make sure that communication between the subnets is configured in advance. |
Terminology
|
Term |
Definition |
|---|---|
|
Primary |
The active server or servers of the high availability pair that is in control by default. Sometimes referred to as the Master. |
|
Secondary |
The "backup" server or servers that takes control when the primary fails. Sometimes referred to as the Slave. |
|
Management Process |
The process which manages and determines which server is in control. |
|
Idle |
High availability state in which the management process is functional, but the secondary server will not take control even if connectivity is lost with the primary server. |