Focus

HA Clustering Overview

Table of Contents

HA Clustering Overview

Learn about HA clustering use cases and deployments.
A number of Palo Alto Networks® firewall models now support session state synchronization among firewalls in a high availability (HA) cluster of up to 16 firewalls. The HA cluster peers synchronize sessions to protect against failure of the data center or a large security inspection point with horizontally scaled firewalls. In the case of a network outage or a firewall going down, the sessions fail over to a different firewall in the cluster. Such synchronization is especially helpful in the following use cases.
One use case is when HA peers are spread across multiple data centers so that there is no single point of failure within or between data centers. A second multi-data center use case is when one data center is active and the other is standby.
A third HA clustering use case is horizontal scaling, in which you add HA cluster members to a single data center to scale security and ensure session survivability.
HA clusters support a Layer 3 or virtual wire deployment. HA peers in the cluster can be a combination of HA pairs and standalone cluster members. In an HA cluster, all members are considered active; there is no concept of passive firewalls except for HA pairs, which can keep their active/passive relationship after you add them to an HA cluster.
Understand that in the event of a link monitoring or path monitoring failure, an HA cluster does not support the “last device standing” behavior that occurs in a simple HA pair outside of a cluster. Instead, one of the devices in an HA pair within the HA cluster can go into a non-functional loop and suspended state, while the other device of the pair continues to loop on the path monitoring failures. After this non-suspended device reaches its Flap Max setting (which also applies to HA clustering), this device can also go into suspended state. Hence, the “last device standing” behavior does not occur.
Keep in mind that a device in a suspended state can’t move to an HA functional state without your [user] intervention.
All cluster members share session state. When a new firewall joins an HA cluster, that triggers all firewalls in the cluster to synchronize all existing sessions. HA4 and HA4 backup connections are the dedicated cluster links that synchronize session state among all cluster members having the same cluster ID. The HA4 link between cluster members detects connectivity failures between cluster members. HA1 (control link), HA2 (data link), and HA3 (packet-forwarding link) are not supported between cluster members that are not HA pairs.
For a normal session that has not failed over, only the firewall that is the session owner creates a traffic log. For a session that failed over, the new session owner (the firewall that receives the failed over traffic) creates the traffic log.
The firewall models that support HA clustering and the maximum number of members supported per cluster are as follows:
Firewall ModelNumber of Members Supported Per Cluster
PA-3200 Series
6
PA-5200 Series
16
PA-5450
8
PA-7000 Series firewalls that have at least one of the following cards: PA-7000-100G-NPC, PA-7000-20GQXM-NPC, PA-7000-20GXM-NPC
PA-7080: 4
PA-7050: 6
VM-300
6
VM-500
6
VM-700
16
HA clustering isn’t supported in public cloud deployments. Consider the HA Clustering Best Practices and Provisioning before you start to Configure HA Clustering.

How an HA Pair State Affects an HA Cluster State

First, let's understand how an HA pair state maps to an HA cluster state:
HA Pair State
HA Cluster State
unknown
cluster-unknown*
suspended
cluster-suspended*
non-functional
cluster-non-functional*
initial
cluster-initial*
passive
cluster-non-functional*
active
The cluster uses its own state machine; state isn't tied to the HA pair state.
active-primary
active-secondary
tentative
Now, we can look at the following factors that determine how an HA pair state affects an HA cluster state:
  • The HA cluster states marked with an asterisk (*) in the preceding table will adopt the HA pair local device state if the device is in both an HA pair and an HA cluster. For example, if the HA pair state is suspended, the cluster state is cluster-suspended.
  • For an HA pair state of active, active-primary, or active-secondary, the cluster state will be cluster-active if there are no soft failures. In case of soft failures, for an HA pair state of active, active-primary, active-secondary or tentative, the cluster state will follow its own state machine and can be in any cluster state.
  • The HA local device pair state that maps to the cluster-active state can still enter a non-functional cluster state because all faults considered by cluster state are still relevant when an HA local device pair state is active.
    • This means that a member of an HA pair with active state can be in an HA cluster non-functional state, especially if the HA pair active state member is there due to “last device standing.”
    • Soft faults (such as link monitoring failures, path monitoring failures, or slot mismatch errors) would result in a “last device standing” in an HA pair. However, if that HA pair is in an HA cluster, then the HA pair local device continues to honor the faults that are normally ignored when the HA pair peer device state is in one of the states that is not functional.
    • The state machine in an HA pair device behaves differently when the pair is in an HA cluster versus when the pair isn’t in an HA cluster. When the pair is in an HA cluster, the pair behaves more like a standalone cluster device. Therefore, both devices in an HA pair in a data center can behave like a standalone HA cluster device, allowing the entire data center to go into failure if soft faults trigger.