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 Model | Number 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.