High availability
Multiple FortiAuthenticator units can operate as a high availability (HA) cluster to provide even higher reliability.
There are three HA roles:
- Cluster member
- Standalone primary
- Load-balancer
The FortiAuthenticator can operate in two separate HA modes:
- Cluster: Active-passive clustered fail-over mode where all of the configuration is synchronized between the devices.
- Load-balancing: Active-active HA method in which one device acts as the standalone primary with up to ten additional, geographically separated load-balancers. The load can be distributed across the devices using round-robin DNS, Auth/NAS client load distribution, or external load balancing devices. Load-balancing mode is intended for two-factor authentication deployments, as only a subset of the configuration is synchronized between the devices.
Both HA modes can be combined with an HA cluster acting as a standalone primary for geographically distributed load-balancers.
If an HA cluster is configured on an interface (such as port 2) and then disabled, it will not be possible to re-enable HA. This is because, when disabled, the interface's IP address is reconfigured to the interface to allow the administrator to access the newly standalone device. To ensure the port is available for use again in a HA cluster, the IP address must be manually removed. |
AES encryption is used in load-balancing (active-active) and cluster (active-passive) modes. |
Cluster member role
In the cluster member role, one unit is active and the other is on standby. If the active unit fails, the standby unit becomes active. The cluster is configured as a single authentication server on your FortiGate units.
Authentication requests made during failover from one unit to another are lost, but subsequent requests are completed normally. Depending on the state of the primary cluster when the failover occurs, the failover process may take between 30 to 180 seconds to complete.
Cluster mode uses Ethernet broadcasts through UDP/720 as part of its primary/secondary election mechanism and for ongoing communication. Layer 2 connectivity is required between the two devices in an HA cluster, preferably via a crossover cable, as some network devices might block such Ethernet broadcasts. |
Layer 2 connectivity (broadcast packets) is mandatory for discovering the other node in an HA-A-P cluster.
To configure FortiAuthenticator HA:
- On each unit, go to System > Administration > High Availability.
- Enter the following information:
Enable HA Enable HA. Role Select Cluster member.
For more information about the other options, see Standalone Primary and Load Balancer role below.
Maintenance Mode Enable to put the FortiAuthenticator unit of an HA cluster into maintenance mode to remove it from the cluster. Upon entering maintenance mode, if the FortiAuthenticator unit is the active member, it relinquishes the active role and assumes a standby role. While in maintenance mode, the FortiAuthenticator will continue to monitor the status of its HA pair and announce its presence.
When set to Enabled with synchronization, the FortiAuthenticator continues to keep its configuration synchronized with the active member.
When set to Enabled without synchronization, the FortiAuthenticator stops synchronizing its configuration with the active member.
Interface Select a network interface to use for communication between the cluster members. This interface must not already have a IP address assigned and it cannot be used for authentication services. Both units must use the same interface for HA communication. Cluster member IP address Enter the IP address this unit uses for HA-related communication with the other FortiAuthenticator unit. The units must have different addresses. Usually, you should assign addresses on the same private subnet. HA admin access Select the types of administrative access to allow from: Telnet, SSH, HTTPS, GUI, REST API, Fabric, HTTP, and SNMP. Priority Set to Low on one unit and High on the other. Normally, the unit with High priority is the active member. Password Enter a string to use as a shared key for IPsec encryption. This must be the same on both units. Load Balancers Add the other load-balancing cluster members by entering their IP addresses. Monitored interfaces Enable the interfaces you want to monitor.
When specifying one or more monitored interfaces, FortiAuthenticator considers their Ethernet link status in the decision algorithm to determine the active/passive role of each FortiAuthenticator node in a primary cluster.
The number of monitored interfaces with link status "up" takes precedence over the priority setting to decide which FortiAuthenticator node assumes the active role.
Monitored interfaces stability period Define the stability period for the monitored interfaces in seconds, between 0-3600 (or one hour). The default is set to 30
.Node-Specific Default Gateway
Define a default gateway for the FortiAuthenticator device if it differs from the default gateway of the other HA cluster member.
Heartbeat interval
Number of milliseconds between each HA heartbeats sent to the other primary cluster member. The default value is 1000 milliseconds.
Heartbeat lost threshold
Number of consecutive heartbeats from the other primary cluster member that must be missed before declaring it out-of-service. The standby unit uses this measure to trigger a failover. The default value is 6.
The Priority setting is a static value. It allows the administrator to specify which unit to elect as the active member when both units are working equally well (i.e. in a failover situation, the "high priority" setting will not be transferred to the new active member).
- If both units are healthy, the one with high priority will be elected as the active member.
- If the high priority active member goes down, the low priority unit becomes the active member.
- When the low priority member is active and the high priority member comes back online, the high priority member assigns the standby role and syncs from the low priority active member. If the high priority member is synced and remains stable for around five minutes, it takes over and becomes the active member again.
- When the low priority member is active because of an issue with a monitored interface on the high priority member and the high priority member has remained synced with the low priority member, then if the monitored interface status comes back to normal and remains so for the configured monitored interface stability period, the high priority member takes over and becomes the active member again.
- Select OK to apply the settings.
When one unit has become the active member, reconnect to the GUI and complete your configuration. The configuration will automatically be copied to the standby member.
Standalone Primary and Load Balancer role
The load-balancing HA method enables active-active HA across geographically separated locations and Layer 3 networks.
Only the following authentication related features can be synchronized:
- Token and seeds.
- Local user database.
- Remote user database.
- Group mappings.
- Token and user mappings.
- Certificates included in:
- Certificate Management > End Entities > Local Services, excluding firmware (Fortinet) certificates.
- Certificate Management > Certificate Authorities > Local CAs, including firmware (Fortinet) certificates.
- Certificate binding settings for local/remote user accounts.
- SAML configurations:
- IdP settings configured in Authentication > SAML IdP > General.
Realm tables are not synchronized, but the default realm selection (radio button) is. - SP settings configured in Authentication > SAML IdP > Service Providers.
- IdP settings configured in Authentication > SAML IdP > General.
- Administrators with Sync in HA Load Balancing mode enabled.
Other features, such as FSSO cannot be synchronized between devices.
The current synchronization status of the standalone primary to load-balancers can be viewed at Dashboard > HA Status.
The standalone primary is the primary system where users, groups, and tokens are configured. Load-balancers are synchronized to the standalone primary device.
To improve the resilience of the primary system, an active-passive cluster with up to ten load-balancing devices can be configured.
To configure load-balancing HA:
- On each unit, go to System > Administration > High Availability.
- Enter the following information:
- Select OK to apply the settings.
Administrative access to the HA cluster
Administrative access is available through any of the network interfaces using their assigned IP addresses or through the HA interface using the Cluster member IP address, assigned on the System > Administration > High Availability page. In all cases, administrative access is available only if it is enabled on the interface.
Administrative access through any of the network interface IP addresses connects only to the active cluster member. The only administrative access to the standby cluster member is through the HA interface using the standby member’s Cluster member IP address.
Configuration changes made on the active member are automatically pushed to the standby member. The standby member does not permit configuration changes, but you might want to access the unit to change HA settings, or for firmware upgrades, shutdown, reboot, or troubleshooting.
FortiAuthenticator VMs used in a HA cluster each require a license. Each license is tied to a specific IP address. In an HA cluster, all interface IP addresses are the same on the units, expect for the HA interface.
Request each license backed on either the unique IP address of the unit's HA interface or the IP address of a non-HA interface which is the same on both units.
If you disable and then re-enable HA operation, the interface that was assigned to HA communication will not be available for HA use. You must first go to System > Network > Interfaces and delete the IP address from that interface. |
Restoring the configuration
When restoring a configuration to an HA active cluster member, the active member reboots and in the interim the standby member is promoted to the role of active member. When the previous active member returns to service, it becomes a standby member and the existing active member overwrites its configuration, defeating the configuration restore. To avoid this, use the following process when restoring a configuration:
- Shutdown the standby unit.
- Restore the configuration on the active member.
- Wait until the active member is back online.
- Turn on standby member — it will synchronize to the restored configuration after booting up.
Firmware upgrade
For a stable HA configuration, all units in an HA cluster must be running the same firmware version, and have the same sized license for HA devices. |
When upgrading the firmware on FortiAuthenticator devices in an HA cluster, you can perform a coordinated upgrade of both cluster members. During the coordinated upgrade, the cluster upgrades the standby device and then the active device to run the new firmware image. The firmware upgrade takes place without interrupting communication through the cluster. This firmware upgrade method can only be initiated from the active member of the cluster.
The following sequence describes the steps the cluster goes through during a coordinated firmware upgrade.
- The administrator initiates the firmware upgrade from the active member.
- The firmware image transfers to the standby member.
- The firmware upgrades on the standby member.
- The standby member reboots and synchronizes with the active member.
- The firmware upgrade begins on the active member. The standby member becomes the new active cluster member.
- The former active member reboots and synchronizes with the new active member.
- The former active member becomes the active device, and the former standby member becomes the standby device.
If you want to perform the firmware upgrade on each FortiAuthenticator cluster member individually, specific steps must be taken to ensure that the upgrade is successful:
- Start the firmware upgrade on the active member. See Upgrading the firmware.
- Start the firmware upgrade on the new active member (former standby device).
The device reboots. While the active member device is rebooting, the standby member becomes the active member.
The device reboots. After both devices have rebooted, the original active member becomes the active device, while the standby member returns to being the standby device.
If a situation arises where both devices are claiming to be the active cluster member due to a firmware mismatch, and the HA port of the device that is intended to be the standby member cannot be accessed (such as when a crossover cable is used), use the following steps:
- Shutdown the active cluster member to which you have access, or, if physical access to the unit is not available to turn it back on, reboot the device. See System information widget.
- With the previously inaccessible device now accessible, upgrade its firmware to the required version so that both devices have the same version.
- If you shutdown the device in Step 1, power it back on.
Note that, if rebooting the device, Step 2 below must be completed before the device finishes rebooting, which can be as short as 30 seconds.
The device reboots.
After both devices are back online, they assume the HA roles dictated by their respective HA priorities.