Fortinet black logo

Overview

7.2.0
Copy Link
Copy Doc ID c40d1e62-9b3a-11ed-8e6d-fa163e15d75b:299094
Download PDF

Overview

This document provides the steps necessary for configuring High Availability. It is intended to be used in conjunction with the Deployment Guide in the Fortinet Document Library.

Note: This document applies to appliances running on the FortiNAC-OS platform.

What it Does

The FortiNAC High Availability solution is used for disaster recovery: ensuring redundancy for FortiNAC. This is achieved through active and passive appliances where the passive (backup) appliance becomes active when the main appliance is no longer functioning normally.

Time duration to change control: The process that activates the backup appliance (fail over), as well as re-activates the main appliance (resume control), takes approximately 10-15 minutes to complete. During this time, FortiNAC processes are not running.

Availability Percentage: Between 99% (“two nines”) and 99.5% (“two and a half nines”).

Reference:

https://en.wikipedia.org/wiki/High_availability

https://interworks.com/blog/rclapp/2010/05/06/what-does-availabilityuptime-mean-real-world/

High Availability Solutions versus Fault Tolerant Solutions

A fault tolerant environment has no service interruption but a significantly higher cost. A highly available environment has a minimal service interruption.

How it Works

The High Availability solution consists of the following components. For more details see High Availability Concepts:

  • 1-to-1 active/passive configuration: for each appliance running (active), there is an appliance in standby (passive).

    • Primary Server - The appliance(s) of the high availability pair that is in control by default.

    • Secondary Server - The "backup" appliance(s) that takes control when the Primary fails.

  • 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 the primary appliances are no longer able to perform all the necessary services and tasks (referred to as “fail over”).

    Scenarios that will trigger a fail over:

    • One of the required services stopped running. If stopped, the process tries to restart it. If the service cannot restart, primary appliance sends a message to the secondary to take over. For details, see Required services.

    • Secondary appliance cannot contact the primary appliance. For details, see Monitoring server communication.

    Additionally, it starts the primary appliances and other required tasks when the primary appliances resume control (referred to as “recovery”). For details, see Recovery.

  • 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.

Terminology

Term

Definition

Primary

The active server or servers of the high availability pair that is in control by default.

Secondary

The "backup" server or servers that take control when the primary fails.

Loader

The process that runs on the FortiNAC Server in Control:

Principal (FortiNAC Server)

Nessus (FortiNAC Server)

Control Manager (FortiNAC Control Manager (NCM))

Management Process

(Control 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.

Requirements

  • Both FortiNAC servers must match all of the following:

    • Model (FNC-CAX-VM, FNC-CA-500F, FNC-CA-600F , FNC-CA-700F, FNC-MX-VM, FNC-M-550F)

    • Virtual Appliance Vendor (Hyper-V, AWS, Azure, etc)

    Configuration Examples

    Supported

    (Primary/Secondary)

    Not Supported

    (Primary/Secondary)

    FNC-CA-500F / FNC-CA-500F

    FNC-CAX-VM (AWS) / FNC-CAX-VM (AWS)

    FNC-M-550F / FNC-M-550F

    FNC-MX-VM (VMware) / FNC-MX-VM (VMware)

    FNC-CA-500F / FNC-CA-600F

    FNC-CAX-VM / FNC-CA-xxxF

    FNC-CAX-VM / FNC-CA-VM

    FNC-CAX-VM (AWS) / FNC-CAX-VM (KVM)

    FNC-MX-VM / FNC-M-550F

    FNC-MX-VM (VMware) / FNC-MX-VM (AWS)

  • The following have been completed for both appliances (see Deployment Guide)

    • Appliance Configuration

      • Configured for Layer 3 Network Type (required for L3 High Availability). See Configuration Wizard reference manual.

      • port2 must be configured with an IP address and DHCP scope. See Required Processes for additional information.

    • Operating System Updates

  • Appliances can ping each other and establish SSH communication.

  • Appliances can ping the default gateway for their port1 interface. For details see Determine Gateway IP Addresses.

  • If using Rogue DHCP Server Detection:

    • Both the primary and Secondary Servers must have the same Interface setting.

    • The ports to which the Interfaces connect must be added to the System DHCP Port group. For instructions, see section Modify a Group of the Administration Guide in the Fortinet Document Library.

    • In the event of a failover, it is important that these fields be set up correctly or DHCP monitoring will not run. For details, see section Rogue DHCP Server Detection of the Administration Guide in the Fortinet Document Library.

Considerations

The Primary Server does not automatically resume control under any circumstance. It must be done manually.

Where to Install the Secondary Server

When choosing the Secondary Server location, network bandwidth and traffic flow change must be taken into account.

  • Starting latency and bandwidth recommendations (L2 & L3 configurations):

    • Latency between remote data nodes must not exceed 20 milliseconds

    • Bandwidth of the network link must be a minimum of 4.8 Mbps

      Fortinet recommends using the "Database Replication Error" event and the corresponding alarm action to notify administrators when an error occurs. There are two possible causes for this error:

    • There was a momentary network outage that caused the failure.

    • If the event happens continuously, then bandwidth must be increased.

  • Communication between Primary and Secondary Servers

    • Database replication

    • Primary Server control resume process (large amounts of information are copied back to the Primary)

  • Traffic redirected to the Secondary Server upon failover

    • Administration UI access

    • FortiNAC Agent communication

    • Infrastructure device communication (e.g. routers, switches, Controllers/AP's)

      • SNMP

      • SSH

      • RADIUS (if Proxy mode, includes communication with RADIUS server)

      • API

      • SSO

Example: RADIUS authentication traffic flow

Primary in Control

client ↔ Wireless Controller/Access Point/Switch ↔ Primary FortiNAC ↔ RADIUS Server

Failover (Secondary in control):

client ↔ Wireless Controller/Access Point/Switch ↔ Secondary FortiNAC ↔ RADIUS Server

Configuration Options

There are two possible High Availability configurations:

  • Layer 2 High Availability:

    • Optional Virtual/Shared IP address (VIP)

      • VIP cannot be configured on Azure virtual appliances

      • Available for GUI access convenience

      • UI access to the Primary and Secondary Server IPs is not supported when VIP is configured

      • Secondary Server UI access can be temporarily enabled to access Configuration Wizard (see Appendix)

      • When the IP address of the appliances are required in network device and agent configurations, it is recommended to use the physical IP address of the Primary and Secondary servers.

    • Both Primary and Secondary Servers reside on the same network. For more details see section Design - Layer 2

    • Provides system redundancy in the event of an appliance failure

  • Layer 3 High Availability:

    • Requirement: FortiNAC appliances must be configured for the L3 Network Type. This configWizard option is used when Isolation Networks are separated from the FortiNAC Appliance's port2 interface by a router.

    • Does not use a Virtual/Shared IP address

    • Primary and Secondary Servers reside on different networks (e.g. Data Center and Disaster Recovery (DR) Data Center). For more details see section Design - Layer 3

    • Provides system redundancy in the event of an appliance failure

    • Full disaster recovery in the event of a location outage

Overview

This document provides the steps necessary for configuring High Availability. It is intended to be used in conjunction with the Deployment Guide in the Fortinet Document Library.

Note: This document applies to appliances running on the FortiNAC-OS platform.

What it Does

The FortiNAC High Availability solution is used for disaster recovery: ensuring redundancy for FortiNAC. This is achieved through active and passive appliances where the passive (backup) appliance becomes active when the main appliance is no longer functioning normally.

Time duration to change control: The process that activates the backup appliance (fail over), as well as re-activates the main appliance (resume control), takes approximately 10-15 minutes to complete. During this time, FortiNAC processes are not running.

Availability Percentage: Between 99% (“two nines”) and 99.5% (“two and a half nines”).

Reference:

https://en.wikipedia.org/wiki/High_availability

https://interworks.com/blog/rclapp/2010/05/06/what-does-availabilityuptime-mean-real-world/

High Availability Solutions versus Fault Tolerant Solutions

A fault tolerant environment has no service interruption but a significantly higher cost. A highly available environment has a minimal service interruption.

How it Works

The High Availability solution consists of the following components. For more details see High Availability Concepts:

  • 1-to-1 active/passive configuration: for each appliance running (active), there is an appliance in standby (passive).

    • Primary Server - The appliance(s) of the high availability pair that is in control by default.

    • Secondary Server - The "backup" appliance(s) that takes control when the Primary fails.

  • 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 the primary appliances are no longer able to perform all the necessary services and tasks (referred to as “fail over”).

    Scenarios that will trigger a fail over:

    • One of the required services stopped running. If stopped, the process tries to restart it. If the service cannot restart, primary appliance sends a message to the secondary to take over. For details, see Required services.

    • Secondary appliance cannot contact the primary appliance. For details, see Monitoring server communication.

    Additionally, it starts the primary appliances and other required tasks when the primary appliances resume control (referred to as “recovery”). For details, see Recovery.

  • 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.

Terminology

Term

Definition

Primary

The active server or servers of the high availability pair that is in control by default.

Secondary

The "backup" server or servers that take control when the primary fails.

Loader

The process that runs on the FortiNAC Server in Control:

Principal (FortiNAC Server)

Nessus (FortiNAC Server)

Control Manager (FortiNAC Control Manager (NCM))

Management Process

(Control 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.

Requirements

  • Both FortiNAC servers must match all of the following:

    • Model (FNC-CAX-VM, FNC-CA-500F, FNC-CA-600F , FNC-CA-700F, FNC-MX-VM, FNC-M-550F)

    • Virtual Appliance Vendor (Hyper-V, AWS, Azure, etc)

    Configuration Examples

    Supported

    (Primary/Secondary)

    Not Supported

    (Primary/Secondary)

    FNC-CA-500F / FNC-CA-500F

    FNC-CAX-VM (AWS) / FNC-CAX-VM (AWS)

    FNC-M-550F / FNC-M-550F

    FNC-MX-VM (VMware) / FNC-MX-VM (VMware)

    FNC-CA-500F / FNC-CA-600F

    FNC-CAX-VM / FNC-CA-xxxF

    FNC-CAX-VM / FNC-CA-VM

    FNC-CAX-VM (AWS) / FNC-CAX-VM (KVM)

    FNC-MX-VM / FNC-M-550F

    FNC-MX-VM (VMware) / FNC-MX-VM (AWS)

  • The following have been completed for both appliances (see Deployment Guide)

    • Appliance Configuration

      • Configured for Layer 3 Network Type (required for L3 High Availability). See Configuration Wizard reference manual.

      • port2 must be configured with an IP address and DHCP scope. See Required Processes for additional information.

    • Operating System Updates

  • Appliances can ping each other and establish SSH communication.

  • Appliances can ping the default gateway for their port1 interface. For details see Determine Gateway IP Addresses.

  • If using Rogue DHCP Server Detection:

    • Both the primary and Secondary Servers must have the same Interface setting.

    • The ports to which the Interfaces connect must be added to the System DHCP Port group. For instructions, see section Modify a Group of the Administration Guide in the Fortinet Document Library.

    • In the event of a failover, it is important that these fields be set up correctly or DHCP monitoring will not run. For details, see section Rogue DHCP Server Detection of the Administration Guide in the Fortinet Document Library.

Considerations

The Primary Server does not automatically resume control under any circumstance. It must be done manually.

Where to Install the Secondary Server

When choosing the Secondary Server location, network bandwidth and traffic flow change must be taken into account.

  • Starting latency and bandwidth recommendations (L2 & L3 configurations):

    • Latency between remote data nodes must not exceed 20 milliseconds

    • Bandwidth of the network link must be a minimum of 4.8 Mbps

      Fortinet recommends using the "Database Replication Error" event and the corresponding alarm action to notify administrators when an error occurs. There are two possible causes for this error:

    • There was a momentary network outage that caused the failure.

    • If the event happens continuously, then bandwidth must be increased.

  • Communication between Primary and Secondary Servers

    • Database replication

    • Primary Server control resume process (large amounts of information are copied back to the Primary)

  • Traffic redirected to the Secondary Server upon failover

    • Administration UI access

    • FortiNAC Agent communication

    • Infrastructure device communication (e.g. routers, switches, Controllers/AP's)

      • SNMP

      • SSH

      • RADIUS (if Proxy mode, includes communication with RADIUS server)

      • API

      • SSO

Example: RADIUS authentication traffic flow

Primary in Control

client ↔ Wireless Controller/Access Point/Switch ↔ Primary FortiNAC ↔ RADIUS Server

Failover (Secondary in control):

client ↔ Wireless Controller/Access Point/Switch ↔ Secondary FortiNAC ↔ RADIUS Server

Configuration Options

There are two possible High Availability configurations:

  • Layer 2 High Availability:

    • Optional Virtual/Shared IP address (VIP)

      • VIP cannot be configured on Azure virtual appliances

      • Available for GUI access convenience

      • UI access to the Primary and Secondary Server IPs is not supported when VIP is configured

      • Secondary Server UI access can be temporarily enabled to access Configuration Wizard (see Appendix)

      • When the IP address of the appliances are required in network device and agent configurations, it is recommended to use the physical IP address of the Primary and Secondary servers.

    • Both Primary and Secondary Servers reside on the same network. For more details see section Design - Layer 2

    • Provides system redundancy in the event of an appliance failure

  • Layer 3 High Availability:

    • Requirement: FortiNAC appliances must be configured for the L3 Network Type. This configWizard option is used when Isolation Networks are separated from the FortiNAC Appliance's port2 interface by a router.

    • Does not use a Virtual/Shared IP address

    • Primary and Secondary Servers reside on different networks (e.g. Data Center and Disaster Recovery (DR) Data Center). For more details see section Design - Layer 3

    • Provides system redundancy in the event of an appliance failure

    • Full disaster recovery in the event of a location outage