Next-Generation Firewall
HA Clustering Overview
Table of Contents
HA Clustering Overview
Learn about HA clustering use cases and deployments.
| Where Can I Use This? | What Do I Need? |
|---|---|
|
For Strata Cloud Manager managed NGFWs:
|
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-3400 Series
|
6
|
|
PA-5200 Series
|
16
|
|
PA-5410, PA-5420, PA-5430, PA-5440, PA-5445, and 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
|
cluster-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, active-secondary, or tentative, the cluster state will follow its own state machine and can be in any cluster state. Other HA pair states will all result in a cluster-non-functional state unless noted otherwise in the preceding table.
- 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 isn’t 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.