| Solution |
Table of Contents:
- General Restrictions for HA Cluster Setup
- Important Factors to consider before converting to HA
- Steps to convert from Standalone to HA mode (GUI Method)
- Steps to convert from Standalone to HA mode (CLI Method)
- After conversion to HA mode
- Additional Reading
In general, all FortiGate models are capable of supporting HA operation using FortiGate Clustering Protocol (FGCP) and can be converted from standalone operation with minimal changes required. However, there are some general restrictions to be aware of for HA cluster setup in-general, and there are also important factors to consider when actually performing the standalone-to-HA conversion.
General Restrictions for HA Cluster Setup
- All cluster members must be the same model of FortiGate. This includes model variants with/without log-disks.
- For example, a cluster can be formed between two FortiGate-61Fs, but not between a FortiGate-60F and a FortiGate-61F.
- All cluster members must be running the same FortiOS firmware version (major, minor, and revision must all match).
- Each cluster member must be individually licensed for support/features. This includes licensing for FortiCare Support, FortiGuard Web Filtering, IPS and Antivirus database updates, VDOMs, etc.
- If one of the cluster members has a lower level of licensing than the rest, then the entire cluster will revert to this lower licensing level (i.e. lowest common denominator of support).
- For example, if Web Filtering licenses expire on one of the cluster members then Web Filtering will cease to work for all cluster members, which could potentially cause an outage.
- A notable exception are FortiTokens, which are assigned and licensed to the HA Primary unit and then "shared" with the other HA cluster members (see also: Technical Tip: FortiToken register and provision process after RMA )
Important Factors to consider before converting to HA
- When HA is enabled, the FortiGate cluster will begin using a Virtual MAC Address for all cluster IP addresses, rather than the original physical MAC address of the Primary FortiGate's interfaces.
- This is not a concern in the long-run, but in the immediate short-term it can result in some network disruption since connected devices (such as network switches or routers) are expecting the FortiGate's IP addresses to be associated with the Physical MAC address, rather than the new Virtual MAC address.
- Eventually, all connected devices in the same broadcast domain as the FortiGate will refresh their ARP table entries to associate the FortiGate IP addresses with the new Virtual MAC Address.
- Keep in mind that any network functions that map based on specific MAC addresses will also need to be updated when the HA cluster is established. For example, DHCP leases are associated by MAC address, so a FortiGate that is receiving a DHCP lease for its interfaces may receive a different IP address after converting to HA.
- Check to see if there are any other FortiGate HA clusters in the same connected networks as the standalone FortiGate before performing the conversion.
- It is strongly recommended to schedule a maintenance window to perform this conversion operation, and to also plan for brief network disruptions as part of the window.
Steps to convert from Standalone to HA mode (GUI Method)
To convert a FortiGate from standalone mode to HA mode using the GUI, use the following steps. Note that this guide assumes that the production environment has one existing FortiGate deployed, with a second (or more) FortiGate waiting to be added (these Secondary units should not be connected to the network at this time).
- Login to the existing production FortiGate's Web GUI using a super_admin account.
- Navigate to System -> HA, then change the Mode dropdown from Standalone to either Active-Active or Active-Passive (the steps required are the same for both modes).
- Configure the following required options for HA:
- Mode: Active-Active or Active-Passive**
- Device priority: 0 to 255 (higher is better; used for electing HA cluster primary)**
- Group ID: 0 to 255 (FortiOS 7.0.1 and earlier) or 0 to 1023 (7.0.2 and later).
- It is strongly recommended to set a non-zero value here to reduce the possibility of future conflicts with other FortiGate HA clusters on the network.
- Note: Group IDs are not configurable in the GUI in FortiOS 7.0, but are configurable in 7.2 and later.
- Group Name: String name for HA cluster group (up to 32 characters long).
- Password: String password for HA cluster.
- The Group Name and Password are used to check if a new FortiGate is allowed to join the HA cluster
- Heartbeat Interfaces: Interface(s) used for heartbeat communication between cluster members.
- If possible, it is recommended to direct-connect HA cluster members together via their heartbeat interfaces, though a network switch can be used if necessary.
- If multiple interfaces are specified for redundancy then Heartbeat Interface Priority can be set (higher is better, and interfaces operate in active/standby capacity).
- ** See Additional Reading section for additional info and documentation.
- Select the OK button to commit the changes.
Related article:
Steps to convert from Standalone to HA mode (CLI Method)
1. Log in to the FortiGate CLI using SSH or via a serial console connection. The serial console would require an on-site technician but is extremely helpful in case of unexpected network disruption.
2. Go to config system ha and configure the following required settings (see GUI method for explanation of settings):
config system ha
set group-id <0-255, 256-1023; default = 0>
set group-name <string>
set mode < a-a | a-p >
set password <string>
set hbdev <interface 1> <integer priority> <interface 2> <integer priority> [...]
set priority <0-255; default = 128>
end
3. When ready, type end and commit the change.
After conversion to HA mode
Once the existing production FortiGate is converted to HA operation, additional Secondary FortiGates can be added to the cluster:
- First, prepare the Secondary units for HA operation by either following the HA setup steps outlined above OR backup the Primary FortiGate and restore the configuration to the Secondary.
- Restoring the configuration has the benefit of reducing/removing the need to sync configurations from the Primary to the Secondary. This can save time and make HA setup less error-prone (particularly for complex configs).
- Ensure that device-specific settings (like hostnames, HA Priority, etc.,) are configured appropriately for each new HA cluster member.
- This isn't always necessary, but rebooting the Secondary unit before proceeding with the next steps can be a good idea, as it ensures that the HA cluster uptime on the Secondary is inferior to existing Primary (i.e. to avoid any confusion with who the primary should be).
- Next, connect only the Heartbeat cables from the Secondary to the Primary. This ensures that the cluster can communicate successfully first, and it also prevents cluster split-brain scenarios from occurring.
- Finally, connect the data/network connections from the Secondary to the rest of the network. These will be identical to the connections that the Primary FortiGate has (i.e. each FortiGate has a matching cable to the same destinations).
By this point, the existing standalone FortiGate has been converted to a full HA cluster.
|
