Description
This article describes the benefits of configuring a dedicated session-sync-dev in an HA (High Availability) FortiGate Cluster, especially in situations where the exchange of session synchronization information is high.
This setup is ideal under any of the following conditions:
- The session volume is elevated through the FortiGate (e.g., thousands to millions of sessions).
- Minimal network latency is essential.
- The setup involves a sophisticated environment where FGCP clusters synchronize via FGSP exclusively over Layer 3, and only when asymmetric traffic is present.
Scope
FortiGate.
Solution
Typically, HA session synchronization (enabled with the session-pickup family of options under config system ha) is handled by the HA heartbeat interfaces. However, while this method is straightforward to set up, it has several major disadvantages:
- Session sync-related traffic will now be flowing over the same link as HA heartbeat traffic and configuration sync traffic, which can lead to link congestion and possibly impact the reliability of the HA cluster's communication.
- HA heartbeat interfaces are active-passive only, meaning that only a single link is being used for the aforementioned traffic (it cannot be scaled across multiple heartbeat interfaces).
- This method of session synchronization is a user-mode solution that has relatively low sync throughput (e.g., it is not capable of high-volume session synchronization and can become bottlenecked).
By comparison, the session-sync-dev option allows administrators to select several interfaces to be used for session synchronization duty, and it enables several advantages:
- Interfaces selected for session-sync-dev duty are utilized in a load-balanced (active-active) way, which means that session synchronization is scalable across multiple interfaces (both from a total bandwidth perspective and from a redundancy perspective).
- The session synchronization performed by session-sync-dev utilizes a different kernel-based code path in FortiOS, which is significantly more performant than the user-mode method used for heartbeat interface-based sync.
- By separating session synchronization away from the main heartbeat interface(s), overall HA cluster stability increases since the heartbeat interface is solely carrying heartbeat and configuration synchronization traffic.
Use the following command to enable session-sync-dev in the HA configuration, specifying all member interfaces that will participate in a load-balanced fashion. Note that it is possible to specify interfaces that are already designated for HA heartbeat duty here, in addition to other interfaces:
config system ha
set session-sync-dev <intf_1> <intf_2> <...>
end
Generally, it is best to utilize separate interfaces from the existing heartbeat interfaces for session-sync-dev interfaces, as this ensures that the heartbeats are never at risk of congestion by session sync traffic. However, in scenarios with limited interfaces available (say only the dedicated HA interfaces on the unit are connected), it can still be beneficial to designate some of the heartbeat interfaces as session-sync-devs so that the FortiGate can benefit from the more performant kernel-based session synchronization.
For example, consider a pair of FortiGate-1800Fs in an FGCP cluster with only HA1 and HA2 available for HA purposes. One option for enabling session-sync-dev is to have HA1 configured as the preferred heartbeat interface (via increased priority) and HA2 set as both a heartbeat interface and as a session-sync-dev:
config system ha
set hbdev 'ha1' 100 'ha2' 50
set session-sync ha2
end
In typical operation, this would offload session sync from HA1 to HA2 (leaving HA1 unburdened by session sync duty), and if HA2 fails, then HA1 will automatically resume session sync duty as the available heartbeat interface. Likewise, if HA1 fails, then HA2 will take over both heartbeat and session-sync duty. Note that this solution, while better than not using session-sync-dev at all, is not as good as having fully-separate session-sync-dev interfaces.
Key factors to consider when deciding to use session-sync-dev in FortiGate configuration include:
- High Session Synchronization Requirements.
- Telco/ISP Environments.
- Enhanced Fault Tolerance.
- Load Balancing.
- Scalability Requirements.
- Redundancy Needs.
- Mission-Critical Applications.
Additional Note:
Session synchronization packets use Ethertype 0x8892. Much like heartbeat interfaces, session-sync-dev interfaces are strongly recommended to be directly-connected between HA cluster members, though network switches may be used as intermediaries if necessary (e.g., physically distant cluster members, or more than two members in the cluster). If one of the interfaces becomes disconnected, the cluster uses the remaining interfaces for session synchronization. If all of the session synchronization interfaces become disconnected, session synchronization falls back automatically to using the HA heartbeat interface. All session synchronization traffic is between the primary unit and each subordinate unit.
Related articles:
Technical Tip: FortiGate HA Sessions synchronization
Technical Note: How to increase session-sync performance on a SLBC cluster
Technical Tip: FortiGate High Availability Resource List
