Fortinet 40 FortiWeb 5.0 Patch 6 Administration Guide
After the failover, FortiWeb B would receive the next HTTP request in the session. Because it
was previously the standby when the client initiated the session, and FortiWeb session tables
are not synchronized, FortiWeb B has no knowledge of the FortiWeb session cookie in this
request.
As a result, it cannot enforce sequence-specific features such as page order, since it does not
know the session history. However, a FortiWeb session cookie is present. Therefore FortiWeb B
would permit the new request (assuming that it has no policy violations).
Figure 7: Session continuation after failover to FortiWeb B — Unknown cookie accepted
If the client deletes their FortiWeb session cookie or it times out, FortiWeb B regards the next
request as a new FortiWeb session, adding a new FortiWeb session cookie to Magento’s
response and creating an entry in FortiWeb B’s session table, enabling it to enforce page order
and start page rules again.
HA heartbeat & synchronization
You can group multiple FortiWeb appliances together as a high availability (HA) cluster (see
“Configuring a high availability (HA) FortiWeb cluster” on page 97). The heartbeat traffic
indicates to other appliances in the HA cluster that the appliance is up and “alive.”
Synchronization ensures that all appliances in the cluster remain ready to process traffic, even
if you only change one of the appliances.
Heartbeat and synchronization traffic between cluster appliances occur over the physical
network ports selected in Heartbeat Interface. HA traffic uses multicast UDP on port numbers
6065 (heartbeat) and 6056 (synchronization). The HA multicast IP address is 239.0.0.1; it is
hard-coded, and cannot be configured.
Since web application sessions are not the same as FortiWeb sessions, Magento sessions
continue and are unaffected by the failover.
If switches are used to connect heartbeat interfaces between an HA pair, the heartbeat
interfaces must be reachable by Layer 2 multicast.